-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'm using the following piece of code:

==
for (int i = 1; (curr_line = input_file.readLine()) != null; i++) {
    if (i == 1) {
    line_length_ref = curr_line.length();
    }
    else {
         if (curr_line.length() != line_length_ref) {
            System.err.println("Input file must contain same number of columns through rows.");
            System.exit(1);
         }
    } // some other things
    k = i;
}

if (k != line_length_ref) {
// do some things
}
==
The compiler tells me that
* line_length_ref might not have been initialized at L. 6 (numbering
from this first line of code). However, if the else {} block is
launched at some time, line_length_ref will have already been
initialized, so I don't see where's the problem on an algorithmic POV,
* k might not have been initialized.

Do you have any workaround?
- -- 
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
- -- 

Remember. If something can go wrong, it will. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAk2MqtsACgkQM0LLzLt8MhyTWACbBvbEygnJj+oGdHuwD8jVogoz
G+gAnR7Z4yiMZQSjvxtwjQnljV4HfBqG
=MuGy
-----END PGP SIGNATURE-----

Merciadri Luca wrote:

> I'm using the following piece of code:
> 
> ==
> for (int i = 1; (curr_line = input_file.readLine()) != null; i++) {
>     if (i == 1) {
>     line_length_ref = curr_line.length();
>     }
>     else {
>          if (curr_line.length() != line_length_ref) {
>             System.err.println("Input file must contain same number
> of columns through rows.");             System.exit(1);
>          }
>     } // some other things
>     k = i;
> }
> 
> if (k != line_length_ref) {
> // do some things
> }
> ==
> The compiler tells me that
> * line_length_ref might not have been initialized at L. 6 (numbering
> from this first line of code). However, if the else {} block is
> launched at some time, line_length_ref will have already been
> initialized, so I don't see where's the problem on an algorithmic POV,

You're using line_length_ref outside the loop, but the compiler can't
know if the loop will ever run. If you feed it an empty file, the loop
doesn't even run once becuase readLine() will return null immediately.

> * k might not have been initialized.

Same problem.
 
> Do you have any workaround?
> - -- 

You appear to want to read the file while there are still lines to
read. Logically, a while loop would seem more appropriate here:

rowsRead = 0;
lineLengthRef = 0;
while ( currentLine = inputFile.readLine() != null )
   if ( lineLengthRef == 0 ) // then this is the first line read
   {
      lineLengthRef = currentLine.length();
   }
   else if ( currentLine.length() != lineLengthRef )
   {
      // error
   }

   // some other things   

   rowsRead++;
}

if ( rowsRead != lineLengthRef )
{
   // other things
}

I took the liberty of using some more descriptive variable names and
using the camel-casing typcially used in Java.

By giving the variables initial values before entering the loop, you
know they'll always contain something. I'll leave it to you to
determine if the "other things" in the conditional after the loop make
sense for 0 rows with 0 lineLengthRef.

Alex

On 03/25/2011 10:46 AM, Merciadri Luca wrote:
> The compiler tells me that
> * line_length_ref might not have been initialized at L. 6 (numbering
> from this first line of code). However, if the else {} block is
> launched at some time, line_length_ref will have already been
> initialized, so I don't see where's the problem on an algorithmic POV,

When Java determines initialization semantics, it takes a very 
conservative approach, since the full problem is actually provably 
impossible to compute.

The compiler doesn't know that the variable i will have had to be 1 at 
some point in time. All it knows is that the variable has definitely 
been introduced, since the initialization of i precedes the loop on all 
paths through the control flow graph. To be conservative, it will assume 
that the if statement will never have been executed when it enters the 
else statement, hence the potential uninitialization werror.

> * k might not have been initialized.

This is a case where your analysis is wrong, and it's not that the 
compiler isn't smart enough. What if the loop is never executed, i.e., 
the file is empty?

> Do you have any workaround?

Initialize the values to some default value first, like -1 or 0, when 
you declare them.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 03/25/2011 11:59 AM, Alex Mentis wrote:
> Merciadri Luca wrote:
>> I'm using the following piece of code:
>>
>> ==
>> for (int i = 1; (curr_line = input_file.readLine()) != null; i++) {
>>      if (i == 1) {
>>      line_length_ref = curr_line.length();
>>      }
>>      else {
>>           if (curr_line.length() != line_length_ref) {
>>              System.err.println("Input file must contain same number
>> of columns through rows.");             System.exit(1);
>>           }
>>      } // some other things
>>      k = i;
>> }
>>
>> if (k != line_length_ref) {
>> // do some things
>> }
>> ==
>> The compiler tells me that
>> * line_length_ref might not have been initialized at L. 6 (numbering

That's because you didn't guarantee the initialization in your code.  The 
message is to alert you to that fact.

>> from this first line of code). However, if the else {} block is
>> launched at some time, line_length_ref will have already been
>> initialized, so I don't see where's the problem on an algorithmic POV,

The compiler doesn't have your special run-time knowledge.  It doesn't know 
what the value of 'i' will be at runtime when it does the analysis of line 
"6", so it has to issue the error.

You also use the 'line_length_ref' after the loop in a way that even you 
cannot know will be safe.

RTFM for what the rules actually are.

> You're using line_length_ref outside the loop, but the compiler can't
> know if the loop will ever run. If you feed it an empty file, the loop
> doesn't even run once becuase readLine() will return null immediately.
>
>> * k might not have been initialized.
>
> Same problem.
>
>> Do you have any workaround?

Yes, make sure the variable is definitely assigned and fix your bug.

....
> I took the liberty of using some more descriptive variable names and
> using the camel-casing typcially used in Java.

Thus setting a good example for the OP about the Java conventions.

> By giving the variables initial values before entering the loop, you
> know they'll always contain something. I'll leave it to you to

That's one way, not the only way.

> determine if the "other things" in the conditional after the loop make
> sense for 0 rows with 0 lineLengthRef.

The rules for "definitely assigned" and "definitely unassigned" are spelled 
out explicitly in the Java Language Specification (JLS).  Those are the rules 
the compiler must obey, not yours.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Merciadri Luca <Luca.Merciadri@student.ulg.ac.be> writes:

> Hi,
>
> I'm using the following piece of code:
>
> ==
> for (int i = 1; (curr_line = input_file.readLine()) != null; i++) {
>     if (i == 1) {
>     line_length_ref = curr_line.length();
>     }
>     else {
>          if (curr_line.length() != line_length_ref) {
>             System.err.println("Input file must contain same number of columns through rows.");
>             System.exit(1);
>          }
>     } // some other things
>     k = i;
> }
>
> if (k != line_length_ref) {
> // do some things
> }
> ==
> The compiler tells me that
> * line_length_ref might not have been initialized at L. 6 (numbering
> from this first line of code). However, if the else {} block is
> launched at some time, line_length_ref will have already been
> initialized, so I don't see where's the problem on an algorithmic POV,
> * k might not have been initialized.
>
> Do you have any workaround?
Thanks all for your precious answers.

- -- 
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
- -- 

If you don't buy a ticket, you can't win the raffle.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAk2M2UUACgkQM0LLzLt8MhzHGgCfed2VeTis8n2XiCU8clIfZok+
6UcAoIEgrL3mgcDoKUr/jojIy/+Z1dhN
=wRL8
-----END PGP SIGNATURE-----

On Fri, 25 Mar 2011 15:46:52 +0100, Merciadri Luca
<Luca.Merciadri@student.ulg.ac.be> wrote, quoted or indirectly quoted
someone who said :

>The compiler tells me that
>* line_length_ref might not have been initialized at L. 6 (numbering
>from this first line of code). However, if the else {} block is
>launched at some time, line_length_ref will have already been
>initialized, so I don't see where's the problem on an algorithmic POV,
>* k might not have been initialized.
>
>Do you have any workaround?

In general the compiler uses some rough and ready conservative logic
to decide if something might not get initialised. You simply have to
humour it.  Usually it is correct. You forgot to consider the
possibility of exceptions being thrown unexpectedly.

I did not look at the details of precisely why in your case. Your way
of formatting code makes analysing it painful.  Please have a look at
some of the code examples on my site to see how to indent to make code
readable.  
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
If you think it’s expensive to hire a professional to do the job, wait until you hire an amateur.
~ Red Adair

Roedy Green <see_website@mindprod.com.invalid> wrote in 
news:b64qo6dif9cjoob5cnv098lv8gf5b7ub4u@4ax.com:

> On Fri, 25 Mar 2011 15:46:52 +0100, Merciadri Luca
> <Luca.Merciadri@student.ulg.ac.be> wrote, quoted or indirectly quoted
> someone who said :
> 
>>The compiler tells me that
>>* line_length_ref might not have been initialized at L. 6 (numbering
>>from this first line of code). However, if the else {} block is
>>launched at some time, line_length_ref will have already been
>>initialized, so I don't see where's the problem on an algorithmic POV,
>>* k might not have been initialized.
>>
>>Do you have any workaround?
> 
> In general the compiler uses some rough and ready conservative logic
> to decide if something might not get initialised. You simply have to
> humour it.  Usually it is correct. You forgot to consider the
> possibility of exceptions being thrown unexpectedly.
> 
<snip>

And to answer your question about a workaround...

Somewhere (not shown), you have:

    int line_length_ref;

Replace this with:

    int line_length_ref = 0;

to appease the compiler.

You did not show all of your code or provide an SSCCE so I cannot verify 
this, but it is likely to work.

Ian Shef wrote:
> Roedy Green  wrote:
>> Merciadri Luca wrote, quoted or indirectly quoted someone who said :
>
>>> The compiler tells me that
>>> * line_length_ref might not have been initialized at L. 6 (numbering
>>> from this first line of code). However, if the else {} block is
>>> launched at some time, line_length_ref will have already been
>>> initialized, so I don't see where's the problem on an algorithmic POV,
>>> * k might not have been initialized.
>>>
>>> Do you have any workaround?
>

>> In general the compiler uses some rough and ready conservative logic
>> to decide if something might not get initialised. You simply have to
>> humour it. =A0Usually it is correct. You forgot to consider the
>> possibility of exceptions being thrown unexpectedly.
>

> <snip>
>
> And to answer your question about a workaround...
>
> Somewhere (not shown), you have:
>
> =A0 =A0 int line_length_ref;
>
> Replace this with:
>
> =A0 =A0 int line_length_ref =3D 0;
>
> to appease the compiler.
>
> You did not show all of your code or provide an SSCCE so I cannot verify
> this, but it is likely to work.
>

Or just ensure that the variable is definitely assigned through each
code path.

--
Lew

Lew <lew@lewscanon.com> wrote in news:0481a2e4-7b97-4f0d-83b6-7c6c0ba5209e@
34g2000pru.googlegroups.com:

> Ian Shef wrote:
>> Roedy Green  wrote:
>>> Merciadri Luca wrote, quoted or indirectly quoted someone who said :
>>
>>>> The compiler tells me that
>>>> * line_length_ref might not have been initialized at L. 6 (numbering
>>>> from this first line of code). However, if the else {} block is
>>>> launched at some time, line_length_ref will have already been
>>>> initialized, so I don't see where's the problem on an algorithmic POV,
>>>> * k might not have been initialized.
>>>>
>>>> Do you have any workaround?
>>
> 
>>> In general the compiler uses some rough and ready conservative logic
>>> to decide if something might not get initialised. You simply have to
>>> humour it. �Usually it is correct. You forgot to consider the
>>> possibility of exceptions being thrown unexpectedly.
>>
> 
>> <snip>
>>
>> And to answer your question about a workaround...
>>
>> Somewhere (not shown), you have:
>>
>> � � int line_length_ref;
>>
>> Replace this with:
>>
>> � � int line_length_ref = 0;
>>
>> to appease the compiler.
>>
>> You did not show all of your code or provide an SSCCE so I cannot verify
>> this, but it is likely to work.
>>
> 
> Or just ensure that the variable is definitely assigned through each
> code path.

I hope that this is some form of humor.  The Java compiler is doing this 
check but, based on the volume and nature of the questions from the OP in 
comp.java.lang.help lately, delving into the rules of definite assignment may 
be excessive in this phase of the OP's learning.

For those that are ready to learn, definite assignment is covered in Chapter 
16 (yes, the entire chapter, all 25 pages!) of the JLS (third edition).

> 
> --
> Lew
>