Re: Missing warning about uninitialized variable.

Re: Missing warning about uninitialized variable.

[J.C. Pizarro]

On 2007/11/29, Mikael Vidstedt <mikael.vidstedt@bea.com> wrote:
> The following program may make use of an uninitialized variable (gurka):
>
> int
> main(int argc, char* argv[])
> {
>    int gurka;
>
>    if(argc == 10) {
>       gurka = 3;
>    }
>
>    // gurka isn't necessarily initialized here...
>    printf("%d\n", gurka);
>
>    return 0;
> }
>
> GCC 4.0 will give a warning when this program is compiled with "-O
> -Wall". GCC 4.1 and 4.2 do not give that warning. I haven't had the
> possibility to try GCC 4.3.
>
> What say ye?
>
> Thanks,
> Mikael

It prints stochasticly random data too.

gcc version 4.2.3 20071031 (prerelease)

$ gcc -Wall -o foo foo.c
foo.c: In function 'main':
foo.c:11: warning: implicit declaration of function 'printf'
foo.c:11: warning: incompatible implicit declaration of built-in
function 'printf'
$ for i in $(seq 1 5); do ./foo $(seq 1 10) ; done
-1209020420
-1208291332
-1208422404
-1208803332
-1208823812
$

   J.C.Pizarro

Re: Missing warning about uninitialized variable.

[eschenb]

Aside from the fact, that you obviously forgot a #include <stdio.h>,
of course the output is random, if the variable stays uninitialized (./foo
$seq 1 10) has an argc of 11, doesn't it?

Regards

-Sven

> On 2007/11/29, Mikael Vidstedt <mikael.vidstedt@bea.com> wrote:
>> The following program may make use of an uninitialized variable (gurka):
>>
>> int
>> main(int argc, char* argv[])
>> {
>>    int gurka;
>>
>>    if(argc == 10) {
>>       gurka = 3;
>>    }
>>
>>    // gurka isn't necessarily initialized here...
>>    printf("%d\n", gurka);
>>
>>    return 0;
>> }
>>
>> GCC 4.0 will give a warning when this program is compiled with "-O
>> -Wall". GCC 4.1 and 4.2 do not give that warning. I haven't had the
>> possibility to try GCC 4.3.
>>
>> What say ye?
>>
>> Thanks,
>> Mikael
>
> It prints stochasticly random data too.
>
> gcc version 4.2.3 20071031 (prerelease)
>
> $ gcc -Wall -o foo foo.c
> foo.c: In function 'main':
> foo.c:11: warning: implicit declaration of function 'printf'
> foo.c:11: warning: incompatible implicit declaration of built-in
> function 'printf'
> $ for i in $(seq 1 5); do ./foo $(seq 1 10) ; done
> -1209020420
> -1208291332
> -1208422404
> -1208803332
> -1208823812
> $
>
>    J.C.Pizarro
>

Re: Missing warning about uninitialized variable.

[J.C. Pizarro]

2007/11/29, John Love-Jensen <eljay@adobe.com>:
> Hi J.C.,
>
> Just out of curiosity, what does the 4.2.3 compiler say (if anything) if the
> uninitialized warning is enabled?
>
> $ gcc -O -Wall -o foo foo.c
>
> Thanks,
> --Eljay
>
>

With -O, -O1, -O2, -O3, they print 5 times of value 3
Without optimization, it prints stochasticly random data.

For large projects with uninitialized variables, the behaviour
could be stochasticly flawed as a russian roulette.

  J.C.Pizarro

Re: Missing warning about uninitialized variable.

[J.C. Pizarro]

On 2007/11/29, eschenb@informatik.uni-frankfurt.de
<eschenb@informatik.uni-frankfurt.de> wrote:
> Aside from the fact, that you obviously forgot a #include <stdio.h>,
> of course the output is random, if the variable stays uninitialized (./foo
> $seq 1 10) has an argc of 11, doesn't it?
>
> Regards
>
> -Sven
>
> > On 2007/11/29, Mikael Vidstedt <mikael.vidstedt@bea.com> wrote:
> >> The following program may make use of an uninitialized variable (gurka):
> >>
> >> int
> >> main(int argc, char* argv[])
> >> {
> >>    int gurka;
> >>
> >>    if(argc == 10) {
> >>       gurka = 3;
> >>    }
> >>
> >>    // gurka isn't necessarily initialized here...
> >>    printf("%d\n", gurka);
> >>
> >>    return 0;
> >> }
> >>
> >> GCC 4.0 will give a warning when this program is compiled with "-O
> >> -Wall". GCC 4.1 and 4.2 do not give that warning. I haven't had the
> >> possibility to try GCC 4.3.
> >>
> >> What say ye?
> >>
> >> Thanks,
> >> Mikael
> >
> > It prints stochasticly random data too.
> >
> > gcc version 4.2.3 20071031 (prerelease)
> >
> > $ gcc -Wall -o foo foo.c
> > foo.c: In function 'main':
> > foo.c:11: warning: implicit declaration of function 'printf'
> > foo.c:11: warning: incompatible implicit declaration of built-in
> > function 'printf'
> > $ for i in $(seq 1 5); do ./foo $(seq 1 10) ; done
> > -1209020420
> > -1208291332
> > -1208422404
> > -1208803332
> > -1208823812
> > $
> >
> >    J.C.Pizarro

It can be other bug more!

Re: Missing warning about uninitialized variable.

[eschenb]

Hi again,

What I meant is: argc never is 10 in your example, thus gurka is always
not initialized and therefore has a random value, which is perfectly
normal.

If gcc should warn about it being potentially not initialized, and if so,
using which command line options - that's a completely different topic.

Regards

-Sven


> On 2007/11/29, eschenb@informatik.uni-frankfurt.de
> <eschenb@informatik.uni-frankfurt.de> wrote:
>> Aside from the fact, that you obviously forgot a #include <stdio.h>,
>> of course the output is random, if the variable stays uninitialized
>> (./foo
>> $seq 1 10) has an argc of 11, doesn't it?
>>
>> Regards
>>
>> -Sven
>>
>> > On 2007/11/29, Mikael Vidstedt <mikael.vidstedt@bea.com> wrote:
>> >> The following program may make use of an uninitialized variable
>> (gurka):
>> >>
>> >> int
>> >> main(int argc, char* argv[])
>> >> {
>> >>    int gurka;
>> >>
>> >>    if(argc == 10) {
>> >>       gurka = 3;
>> >>    }
>> >>
>> >>    // gurka isn't necessarily initialized here...
>> >>    printf("%d\n", gurka);
>> >>
>> >>    return 0;
>> >> }
>> >>
>> >> GCC 4.0 will give a warning when this program is compiled with "-O
>> >> -Wall". GCC 4.1 and 4.2 do not give that warning. I haven't had the
>> >> possibility to try GCC 4.3.
>> >>
>> >> What say ye?
>> >>
>> >> Thanks,
>> >> Mikael
>> >
>> > It prints stochasticly random data too.
>> >
>> > gcc version 4.2.3 20071031 (prerelease)
>> >
>> > $ gcc -Wall -o foo foo.c
>> > foo.c: In function 'main':
>> > foo.c:11: warning: implicit declaration of function 'printf'
>> > foo.c:11: warning: incompatible implicit declaration of built-in
>> > function 'printf'
>> > $ for i in $(seq 1 5); do ./foo $(seq 1 10) ; done
>> > -1209020420
>> > -1208291332
>> > -1208422404
>> > -1208803332
>> > -1208823812
>> > $
>> >
>> >    J.C.Pizarro
>
> It can be other bug more!
>

Re: Missing warning about uninitialized variable.

[J.C. Pizarro]

On 2007/11/29, eschenb@informatik.uni-frankfurt.de
<eschenb@informatik.uni-frankfurt.de> wrote:
> Hi again,
>
> What I meant is: argc never is 10 in your example, thus gurka is always
> not initialized and therefore has a random value, which is perfectly
> normal.
>
> If gcc should warn about it being potentially not initialized, and if so,
> using which command line options - that's a completely different topic.
>
> Regards
>
> -Sven
>
>
> > On 2007/11/29, eschenb@informatik.uni-frankfurt.de
> > <eschenb@informatik.uni-frankfurt.de> wrote:
> >> Aside from the fact, that you obviously forgot a #include <stdio.h>,
> >> of course the output is random, if the variable stays uninitialized
> >> (./foo
> >> $seq 1 10) has an argc of 11, doesn't it?
> >>
> >> Regards
> >>
> >> -Sven
> >>
> >> > On 2007/11/29, Mikael Vidstedt <mikael.vidstedt@bea.com> wrote:
> >> >> The following program may make use of an uninitialized variable
> >> (gurka):
> >> >>
> >> >> int
> >> >> main(int argc, char* argv[])
> >> >> {
> >> >>    int gurka;
> >> >>
> >> >>    if(argc == 10) {
> >> >>       gurka = 3;
> >> >>    }
> >> >>
> >> >>    // gurka isn't necessarily initialized here...
> >> >>    printf("%d\n", gurka);
> >> >>
> >> >>    return 0;
> >> >> }
> >> >>
> >> >> GCC 4.0 will give a warning when this program is compiled with "-O
> >> >> -Wall". GCC 4.1 and 4.2 do not give that warning. I haven't had the
> >> >> possibility to try GCC 4.3.
> >> >>
> >> >> What say ye?
> >> >>
> >> >> Thanks,
> >> >> Mikael
> >> >
> >> > It prints stochasticly random data too.
> >> >
> >> > gcc version 4.2.3 20071031 (prerelease)
> >> >
> >> > $ gcc -Wall -o foo foo.c
> >> > foo.c: In function 'main':
> >> > foo.c:11: warning: implicit declaration of function 'printf'
> >> > foo.c:11: warning: incompatible implicit declaration of built-in
> >> > function 'printf'
> >> > $ for i in $(seq 1 5); do ./foo $(seq 1 10) ; done
> >> > -1209020420
> >> > -1208291332
> >> > -1208422404
> >> > -1208803332
> >> > -1208823812
> >> > $
> >> >
> >> >    J.C.Pizarro
> >
> > It can be other bug more!
> >

Yes eschenb, they are 11 args, but i've found a weird thing.

With -O, -O1, -O2, -O3, they print 5 times of value 3 (when argc == 11)
Without optimization, it prints stochasticly random data (when argc == 11).

Why is it false positive to say it prints 3 when it should print
random data instead of 3 because argc != 10?

There is some strange in the generated program.

For large projects with uninitialized variables, the behaviour
could be stochasticly flawed as a russian roulette.

 J.C.Pizarro

Re: Missing warning about uninitialized variable.

[Tom St Denis]

J.C. Pizarro wrote:
> There is some strange in the generated program.
>
> For large projects with uninitialized variables, the behaviour
> could be stochasticly flawed as a russian roulette.
>   

Can I just end this with "undefined behaviour is not defined?"

If you want to know what is actually going on, fire up gdb, and 
single-step asm operations.  Most likely "3" is some counter in the 
optimized case, (just happens to be) and not in the others.  Who cares, 
it's undefined.

And stop using "stochastically random" too ... that's annoying.  It's 
called "garbage" (not to be confused with MSFT software ...).

:-)

Tom

Re: Missing warning about uninitialized variable.

[J.C. Pizarro]

On 2007/11/29, eschenb@informatik.uni-frankfurt.de
<eschenb@informatik.uni-frankfurt.de> wrote:
> If gcc should warn about it being potentially not initialized, and if so,
> using which command line options - that's a completely different topic.

Warn no! Error yes!

Why?

Many compilations of projects print many warnings as is they
have not problems! But ...

     For large projects with uninitialized variables, the behaviour
     could be stochasticly flawed as a russian roulette.

With Error instead of Warn, they abort the compilations for later
repairing of theirs bugs and avoiding the scenario of russian roulette.

 J.C.Pizarro

Re: Missing warning about uninitialized variable.

[J.C. Pizarro]

On 2007/11/29, Tom St Denis <tstdenis@ellipticsemi.com> wrote:
> J.C. Pizarro wrote:
> > There is some strange in the generated program.
> >
> > For large projects with uninitialized variables, the behaviour
> > could be stochasticly flawed as a russian roulette.
> >
>
> Can I just end this with "undefined behaviour is not defined?"
>
> If you want to know what is actually going on, fire up gdb, and
> single-step asm operations.  Most likely "3" is some counter in the
> optimized case, (just happens to be) and not in the others.  Who cares,
> it's undefined.
>
> And stop using "stochastically random" too ... that's annoying.  It's
> called "garbage" (not to be confused with MSFT software ...).

Q: What does it print?
A: Random data.

Q: How does it print?
A: Stochastically.

I said "it prints stochasticly random data". Is it wrong?

>
> :-)
>
> Tom
>

   J.C.Pizarro

Re: Missing warning about uninitialized variable.

[Tom St Denis]

J.C. Pizarro wrote:
> Q: What does it print?
> A: Random data.
>
> Q: How does it print?
> A: Stochastically.
>
> I said "it prints stochasticly random data". Is it wrong?
>   

Yes.

Stochastic, Adjective: of or pertaining to a process involving a 
randomly determined sequence of observations each of which is considered 
as a sample of one element from a probability distribution.

It's not "stochastically" printing anything.  In fact, for any given 
instance of the compiled unit, it's entirely predictable what's going to 
happen.  Just look at the machine code.  And it's hardly random data 
anyways.  5 32-bit numbers where most of the bits are the same is hardly 
"random."  At best, they're different, and more correctly, undefined.

You don't need to invent terminology. 

int a;
printf("a == %d\n", a);

That's not "random," nor is it "stochastic," or even "perplexing!" for 
that matter.  It's undefined.  I can't tell you what that will print.  
But I can justify what it did print [if that makes any sense...].

Tom

Re: Missing warning about uninitialized variable.

[John Love-Jensen]

Hi J.C.

> Yes eschenb, they are 11 args, but i've found a weird thing.
> 
> With -O, -O1, -O2, -O3, they print 5 times of value 3 (when argc == 11)
> Without optimization, it prints stochasticly random data (when argc == 11).

That is not a weird thing.  And it is unlikely that the non-optimized case
the data is actually stochastically random -- more likely there is a reason
it is the value it has.  For instance (pure speculation), the value may be a
left-over stack value for the PID.  In that the value isn't the same from
run-to-run could be a factor of the PID not being identical from run-to-run.

> Why is it false positive to say it prints 3 when it should print
> random data instead of 3 because argc != 10?

Uninitialized data is not the same thing as random data.

> There is some strange in the generated program.

No, consistently valued uninitialized data is not strange, especially for an
optimized program.  In the optimized program case, the previous "random"
value may still be present, but the location of the variable in stack memory
may have been optimized to a different location, which now has a
consistently valued uninitialized value.

> For large projects with uninitialized variables, the behaviour
> could be stochasticly flawed as a russian roulette.

Correct.

Uninitialized variables is, in my opinion, a serious shortcoming in C and
C++.

In my opinion, the DEFAULT behavior should be initialized to some known
value that can be relied upon, and extra measures should need to be taken to
tell the compiler NOT to initialize the variable.

That's all well and good, but it's not C or C++.

Adding that to C or C++ would make a variant language that
is-close-to-but-not-quite the standard language.

I've tried my hand at making my own general purpose language, and have given
up.  I think to do a good job would require many years of focused
dedication, and I just don't have the patience.  Fortunately, Walter Bright
does have the stamina and wherewithal, and created the D Programming
Language which implements 90%+ of the way I envisioned my aborted attempt,
and then some!  My only minor complaints are C++-esque "const correctness",
C++-esque I/O streams, and "wish it had overloading".  Kudos, Walter Bright!

Sincerely,
--Eljay

Re: Missing warning about uninitialized variable.

[J.C. Pizarro]

On 2007/11/29, John Love-Jensen <eljay@adobe.com> wrote:
> Hi J.C.
>
> > Yes eschenb, they are 11 args, but i've found a weird thing.
> >
> > With -O, -O1, -O2, -O3, they print 5 times of value 3 (when argc == 11)
> > Without optimization, it prints stochasticly random data (when argc == 11).
>
> That is not a weird thing.  And it is unlikely that the non-optimized case
> the data is actually stochastically random -- more likely there is a reason
> it is the value it has.  For instance (pure speculation), the value may be a
> left-over stack value for the PID.  In that the value isn't the same from
> run-to-run could be a factor of the PID not being identical from run-to-run.

Not PID only! ELF loader too!

r$ for i in $(seq 1 5); do ldd foo ; done
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7db2000)
        /lib/ld-linux.so.2 (0xb7ef2000)
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7e0f000)
        /lib/ld-linux.so.2 (0xb7f4f000)
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7dcc000)
        /lib/ld-linux.so.2 (0xb7f0c000)

ELF loader loads the same program stochasticly different addresses.
I think it does by security's reasons, i don't know more.

> > Why is it false positive to say it prints 3 when it should print
> > random data instead of 3 because argc != 10?
>
> Uninitialized data is not the same thing as random data.

Don't exist "uninitialized data".
They exist "uninitialized variables". They exist "uninitialized arrays". Etc.
How "data" are unitialized? Weird!

I know, it in the "uninitialized" thing appears random data.
But, it is possible that in the "uninitialized" thing appears an
uncorrespondent const data.

> > There is some strange in the generated program.
>
> No, consistently valued uninitialized data is not strange, especially for an
> optimized program.  In the optimized program case, the previous "random"
> value may still be present, but the location of the variable in stack memory
> may have been optimized to a different location, which now has a
> consistently valued uninitialized value.

I haven't yet dissambled the program foo.
It's possible that in the location of the uninitialized variable it has the
surprise of to appear the value 3 (e.g. abandoned in the stack).
I haven't debugged the "optimized?" program (-g with -O3, is it incompatible?)

> Sincerely,
> --Eljay

   J.C.Pizarro, sincerely.

Re: Missing warning about uninitialized variable.

[J.C. Pizarro]

On 2007/11/29, Tom St Denis <tstdenis@ellipticsemi.com> wrote:
> J.C. Pizarro wrote:
> > Q: What does it print?
> > A: Random data.
> >
> > Q: How does it print?
> > A: Stochastically.
> >
> > I said "it prints stochasticly random data". Is it wrong?
> >
>
> Yes.
>
> Stochastic, Adjective: of or pertaining to a process involving a
> randomly determined sequence of observations each of which is considered
> as a sample of one element from a probability distribution.
>
> It's not "stochastically" printing anything.  In fact, for any given
> instance of the compiled unit, it's entirely predictable what's going to
> happen.  Just look at the machine code.  And it's hardly random data
> anyways.  5 32-bit numbers where most of the bits are the same is hardly
> "random."  At best, they're different, and more correctly, undefined.

http://en.wikipedia.org/wiki/Stochastic says

"A stochastic process is one whose behavior is non-deterministic in
that a state does not fully determine its next state."

In this case, printing it above is a stochastic process, a stochastic
running program.

http://en.wikipedia.org/wiki/Stochastic_process says

"A stochastic process, or sometimes random process, is the opposite of
a deterministic process (or deterministic system) in probability
theory. Instead of dealing only with one possible 'reality' of how the
process might evolve under time (as is the case, for example, for
solutions of an ordinary differential equation), in a stochastic or
random process there is some indeterminacy in its future evolution
described by probability distributions."

My input's sequence for the program was { 1 to 10, 1 to 10, 1 to 10, 1
to 10, 1 to 10 }
and the output's sequence was { sequence of random data and inestimable }.

> You don't need to invent terminology.

He, he, he, he,
why can't invent the existent or unexistent wheel as the people does?

> int a;
> printf("a == %d\n", a);
>
> That's not "random," nor is it "stochastic," or even "perplexing!" for
> that matter.  It's undefined.  I can't tell you what that will print.
> But I can justify what it did print [if that makes any sense...].
>
> Tom

It's not a "functional programming", it's an "imperative programming",
they are different.

   J.C.Pizarro

Re: Missing warning about uninitialized variable.

[Tom St Denis]

J.C. Pizarro wrote:
> My input's sequence for the program was { 1 to 10, 1 to 10, 1 to 10, 1
> to 10, 1 to 10 }
> and the output's sequence was { sequence of random data and inestimable }.
>   
Ok, first off, I'm a cryptographer so "random" has an actual meaning to 
me, as oppose to "undetermined."

Second, there is a difference between "undefined" and "random." 

Third, those numbers are NOT random.  5 32-bit numbers should have quite 
a few different bits between them.  If I took two 32-bit numbers I'd 
expect on average at least 16 bits to be different between them (well 
more so, that'd be the most likely outcome).

Fourth, it's not a "random process."  The compiled instance of your 
undefined code will follow a very logical and predictable course given 
the current contents of unitialized memory. 

suppose in

int a;
printf("a = %d\n", a);

The memory for "a" contained the int "5" . This is undefined code, as 
in, the standard has no prescribed behaviour for the resulting program.  
However, it WILL print "5" every time the "a" variable contains 5.  It 
WILL do that.  As in, it's NOT a random process.

>> int a;
>> printf("a == %d\n", a);
>>
>> That's not "random," nor is it "stochastic," or even "perplexing!" for
>> that matter.  It's undefined.  I can't tell you what that will print.
>> But I can justify what it did print [if that makes any sense...].
>>
>> Tom
>>     
>
> It's not a "functional programming", it's an "imperative programming",
> they are different.
>   
?

Use terminology from the standard if you're going to use anything.  What 
I wrote is a syntactically correct program (hence it compiles).  It's 
just not going to produce a defined behaviour (since a is uninitialized).

Here is your homework list of words to learn

- undefined
- defined
- behaviour
- deterministic
- initialized [and uninitialized]

I understand that English is likely not your first language, but please 
stop trying to invent new terminology.  Explain what you mean in simple 
English, and we can help you explain it in terminology prescribed by the 
standards.

Tom

Re: Missing warning about uninitialized variable.

[Sven Eschenberg]

J.C. Pizarro schrieb:
> On 2007/11/29, eschenb@informatik.uni-frankfurt.de
> <eschenb@informatik.uni-frankfurt.de> wrote:
>   
>> If gcc should warn about it being potentially not initialized, and if so,
>> using which command line options - that's a completely different topic.
>>     
>
> Warn no! Error yes!
>
> Why?
>
> Many compilations of projects print many warnings as is they
> have not problems! But ...
>
>      For large projects with uninitialized variables, the behaviour
>      could be stochasticly flawed as a russian roulette.
>
> With Error instead of Warn, they abort the compilations for later
> repairing of theirs bugs and avoiding the scenario of russian roulette.
>
>  J.C.Pizarro
>   
Imho, the compiler should at max give a warning, because it is outside 
the compilers semantic abilities to decide, what the programmer wants. I 
think, it's not the compiler's task to tell the programmer, what he 
WANTS to do.

Let's take your example again and imagine the following:

if (argc == 10) gurka=3;
if (argc == 11) gurka=3;

...

at some other point:

switch (gurka){
    case 3:
       printf("gurka is %d, which indicates 10 or 11 params\n, gurka");
       break;
    default:
       printf("Wrong number of paramters, 10 or 11 params expected\n");
      exit (EXIT_FAILURE);
}

Though gurka might be uninitialized it is perfectly okay and as expected.

Let's assume a different scenario:

if (argc%2==0) gurka=0;
else gurka=1;

Here the compiler can detect, that no matter what argc is, gurka is 
initialied (0 for odd, 1 for even), let's take it a step further:

if(argc%3==0) gurka=0;
if (argc%3==1) gurka=1;

now gurka will be 0 for a multiple of 3, 1 for a multiple of 3+1, 
otherwise undefined, because it might be absolutely legal that we don't 
care if argc ist a multipe of 3+2.

Bailing out with an error could be perfectly unreasonable.

Yes, maybe I could as well say gurka=argc%3; then only check for the two 
possibilities I am interested in, but imho it's not the compiler's job 
to force me, to do it this way, if the other possibility is semantically 
legal for the language.

As John(?) said, having a relyable initialization might be a nice 
extension, but it's just not C, after all you could define gurka as:

int gurka=0;

thus enforcing a default value, but it's up to you to decided this, just 
bailing out with an error is not the right thing to do (imho).

Regards

-Sven

RE: Missing warning about uninitialized variable.

[Mikael Vidstedt]

Just a quick question: Did anybody actually read the subject? My question
was not about the value of the variable, it was about recent GCC versions no
longer warn about the use of an uninitialized variable...?

/Mikael

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of Tom St Denis
Sent: den 29 november 2007 19:12
To: J.C. Pizarro
Cc: gcc-help@gcc.gnu.org
Subject: Re: Missing warning about uninitialized variable.

J.C. Pizarro wrote:
> My input's sequence for the program was { 1 to 10, 1 to 10, 1 to 10, 1
> to 10, 1 to 10 }
> and the output's sequence was { sequence of random data and inestimable }.
>   
Ok, first off, I'm a cryptographer so "random" has an actual meaning to 
me, as oppose to "undetermined."

Second, there is a difference between "undefined" and "random." 

Third, those numbers are NOT random.  5 32-bit numbers should have quite 
a few different bits between them.  If I took two 32-bit numbers I'd 
expect on average at least 16 bits to be different between them (well 
more so, that'd be the most likely outcome).

Fourth, it's not a "random process."  The compiled instance of your 
undefined code will follow a very logical and predictable course given 
the current contents of unitialized memory. 

suppose in

int a;
printf("a = %d\n", a);

The memory for "a" contained the int "5" . This is undefined code, as 
in, the standard has no prescribed behaviour for the resulting program.  
However, it WILL print "5" every time the "a" variable contains 5.  It 
WILL do that.  As in, it's NOT a random process.

>> int a;
>> printf("a == %d\n", a);
>>
>> That's not "random," nor is it "stochastic," or even "perplexing!" for
>> that matter.  It's undefined.  I can't tell you what that will print.
>> But I can justify what it did print [if that makes any sense...].
>>
>> Tom
>>     
>
> It's not a "functional programming", it's an "imperative programming",
> they are different.
>   
?

Use terminology from the standard if you're going to use anything.  What 
I wrote is a syntactically correct program (hence it compiles).  It's 
just not going to produce a defined behaviour (since a is uninitialized).

Here is your homework list of words to learn

- undefined
- defined
- behaviour
- deterministic
- initialized [and uninitialized]

I understand that English is likely not your first language, but please 
stop trying to invent new terminology.  Explain what you mean in simple 
English, and we can help you explain it in terminology prescribed by the 
standards.

Tom

Re: Missing warning about uninitialized variable.

[Tom St Denis]

Sven Eschenberg wrote:
> Bailing out with an error could be perfectly unreasonable.

Ideally you should use -Werror and/or perform parameter checking.  a 2 
mod 3 number of parameters may be "invalid" but if you don't actually 
act on it your program cannot be verified.

Granted I never use -Werror as I don't care about a lot of the minor 
violations (.e.g. passing a long to %d in a homebrew behind the scenes 
test program).

Tom

Re: Missing warning about uninitialized variable.

[Tom St Denis]

Mikael Vidstedt wrote:
> Just a quick question: Did anybody actually read the subject? My question
> was not about the value of the variable, it was about recent GCC versions no
> longer warn about the use of an uninitialized variable...?
>   

You have to turn on the optimizer to see that.  As I understand it, it's 
only when the optimizer walks down the tree that it picks up the 
uninitialized bit.

-bash-3.00$ gcc -O -Wall -c warn.c
warn.c: In function `main':
warn.c:4: warning: 'g' might be used uninitialized in this function
-bash-3.00$ cat warn.c
#include <stdio.h>
int main(int argc, char **argv)
{
  int g;
  if (argc == 10) { g = 3; }
  printf("g == %d\n", g);
  return 0;
}

Tom

RE: Missing warning about uninitialized variable.

[Mikael Vidstedt]

At the end of the original message I did include the command lines of three
different compilations, using gcc 4.0.4, 4.1.3 and 4.2.3, all with the same
basic command line: gcc -O -Wall -o foo foo.c

Only the first version, gcc 4.0.4, prints the warning.

Thanks,
Mikael

-----Original Message-----
From: Tom St Denis [mailto:tstdenis@ellipticsemi.com] 
Sent: den 29 november 2007 19:23
To: Mikael Vidstedt
Cc: 'J.C. Pizarro'; gcc-help@gcc.gnu.org
Subject: Re: Missing warning about uninitialized variable.

Mikael Vidstedt wrote:
> Just a quick question: Did anybody actually read the subject? My question
> was not about the value of the variable, it was about recent GCC versions
no
> longer warn about the use of an uninitialized variable...?
>   

You have to turn on the optimizer to see that.  As I understand it, it's 
only when the optimizer walks down the tree that it picks up the 
uninitialized bit.

-bash-3.00$ gcc -O -Wall -c warn.c
warn.c: In function `main':
warn.c:4: warning: 'g' might be used uninitialized in this function
-bash-3.00$ cat warn.c
#include <stdio.h>
int main(int argc, char **argv)
{
  int g;
  if (argc == 10) { g = 3; }
  printf("g == %d\n", g);
  return 0;
}

Tom

Re: Missing warning about uninitialized variable.

[Sven Eschenberg]

Agreed, it was just the fastet example I could come up with, not even 
claiming it might have any usability - considerable you might use enums 
sometimes, to help the compiler, to check that only certain values for a 
variable are 'valid'. formal verification is a completely different topic.
I thought of it as a rather simplistic example where leaving a variable 
in certain cases unitialized is not really an error in the program's 
logic and thus have a compiler produce an error might be 
unwanted/unexpected behavior.

Regards

-Sven


Tom St Denis schrieb:
> Sven Eschenberg wrote:
>> Bailing out with an error could be perfectly unreasonable.
>
> Ideally you should use -Werror and/or perform parameter checking.  a 2 
> mod 3 number of parameters may be "invalid" but if you don't actually 
> act on it your program cannot be verified.
>
> Granted I never use -Werror as I don't care about a lot of the minor 
> violations (.e.g. passing a long to %d in a homebrew behind the scenes 
> test program).
>
> Tom

Re: Missing warning about uninitialized variable.

[J.C. Pizarro]

[-- Attachment #1: Type: text/plain, Size: 120 bytes --]

2007/11/29, J.C. Pizarro <jcpiza@gmail.com>, i wrote:
>    J.C.Pizarro, sincerely, don't fear, i never did touch a gun.

[-- Attachment #2: ishootyou.c --]
[-- Type: application/octet-stream, Size: 852 bytes --]

#include <stdio.h>
#include <string.h>
#include <math.h>
/* It's a security's demonstration of russian roulette. */
/* The uninitialized variable decides to shoot you or not. */
/* The GCC's Warn can't avoid it shoots you. GCC's Error aborts it. */
/* For large projects, it's a big problem to avoid this play,
 *   to imagine that there is a backdoor inside because of this. */
/*        gcc -lm -Wall ishootyou.c -o ishootyou          */
/*        for i in $(seq 1 8); do ./ishootyou ; done      */
int main(int argc, char* argv[]) {
   int uninitialized_var_gurka, yes_or_not;

   if (strcmp(argv[0],"Xshootsyou")==0) uninitialized_var_gurka=0;

   yes_or_not = (((int)(sin(uninitialized_var_gurka)*(double)((unsigned)-1))
		 >> 8) & 1);

   if (yes_or_not) printf("PUM! I shooted you!\n");
   else            printf("You free.\n");

   return 0;
}

Re: Missing warning about uninitialized variable.

[J.C. Pizarro]

On 2007/11/29, Tom St Denis <tstdenis@ellipticsemi.com> wrote:
> J.C. Pizarro wrote:
> > My input's sequence for the program was { 1 to 10, 1 to 10, 1 to 10, 1
> > to 10, 1 to 10 }
> > and the output's sequence was { sequence of random data and inestimable }.
> >
> Ok, first off, I'm a cryptographer so "random" has an actual meaning to
> me, as oppose to "undetermined."
>
> Second, there is a difference between "undefined" and "random."
>
> Third, those numbers are NOT random.  5 32-bit numbers should have quite
> a few different bits between them.  If I took two 32-bit numbers I'd
> expect on average at least 16 bits to be different between them (well
> more so, that'd be the most likely outcome).
>
> Fourth, it's not a "random process."  The compiled instance of your
> undefined code will follow a very logical and predictable course given
> the current contents of unitialized memory.
>
> suppose in
>
> int a;
> printf("a = %d\n", a);
>
> The memory for "a" contained the int "5" . This is undefined code, as
> in, the standard has no prescribed behaviour for the resulting program.
> However, it WILL print "5" every time the "a" variable contains 5.  It
> WILL do that.  As in, it's NOT a random process.
>
> >> int a;
> >> printf("a == %d\n", a);
> >>
> >> That's not "random," nor is it "stochastic," or even "perplexing!" for
> >> that matter.  It's undefined.  I can't tell you what that will print.
> >> But I can justify what it did print [if that makes any sense...].
> >>
> >> Tom
> >>
> >
> > It's not a "functional programming", it's an "imperative programming",
> > they are different.
> >
> ?
>
> Use terminology from the standard if you're going to use anything.  What
> I wrote is a syntactically correct program (hence it compiles).  It's
> just not going to produce a defined behaviour (since a is uninitialized).
>
> Here is your homework list of words to learn
>
> - undefined
> - defined
> - behaviour
> - deterministic
> - initialized [and uninitialized]
>
> I understand that English is likely not your first language, but please
> stop trying to invent new terminology.  Explain what you mean in simple
> English, and we can help you explain it in terminology prescribed by the
> standards.
>
> Tom
>

Puffff, pufff, pufff, ... my language is simple but vulgar.

Dear cryptographer Tom St Denis, you want not to understand
the simple game of russian roulette.

Here there is a demo "ishootyou.c", compile it as it says with gcc
4.1, 4.2 or 4.3
and explain me how is 'undefined' the shooting to you? Hehehehe. I jokes you ;)

#include <stdio.h>
#include <string.h>
#include <math.h>
/* It's a security's demonstration of russian roulette. */
/* The uninitialized variable decides to shoot you or not. */
/* The GCC's Warn can't avoid it shoots you. GCC's Error aborts it. */
/* For large projects, it's a big problem to avoid this play,
 *   to imagine that there is a backdoor inside because of this. */
/*        gcc -lm -Wall ishootyou.c -o ishootyou          */
/*        for i in $(seq 1 8); do ./ishootyou ; done      */
int main(int argc, char* argv[]) {
   int uninitialized_var_gurka, yes_or_not;

   if (strcmp(argv[0],"Xshootsyou")==0) uninitialized_var_gurka=0;

   yes_or_not = (((int)(sin(uninitialized_var_gurka)*(double)((unsigned)-1))
                 >> 8) & 1);

   if (yes_or_not) printf("PUM! I shooted you!\n");
   else            printf("You free.\n");

   return 0;
}

$ gcc -lm -Wall ishootyou.c -o ishootyou
$ for i in $(seq 1 8); do ./ishootyou ; done
PUM! I shooted you!
You free.
You free.
You free.
You free.
PUM! I shooted you!
You free.
PUM! I shooted you!
$

   J.C.Pizarro, sincerely, don't fear, i never did touch a gun.

Re: Missing warning about uninitialized variable.

[J.C. Pizarro]

On 2007/11/29, Tom St Denis <tstdenis@ellipticsemi.com> wrote:
> J.C. Pizarro wrote:
> > My input's sequence for the program was { 1 to 10, 1 to 10, 1 to 10, 1
> > to 10, 1 to 10 }
> > and the output's sequence was { sequence of random data and inestimable }.
> >
> Ok, first off, I'm a cryptographer so "random" has an actual meaning to
> me, as oppose to "undetermined."
>
> Second, there is a difference between "undefined" and "random."
>
> Third, those numbers are NOT random.  5 32-bit numbers should have quite
> a few different bits between them.  If I took two 32-bit numbers I'd
> expect on average at least 16 bits to be different between them (well
> more so, that'd be the most likely outcome).
>
> Fourth, it's not a "random process."  The compiled instance of your
> undefined code will follow a very logical and predictable course given
> the current contents of unitialized memory.
>
> suppose in
>
> int a;
> printf("a = %d\n", a);
>
> The memory for "a" contained the int "5" . This is undefined code, as
> in, the standard has no prescribed behaviour for the resulting program.
> However, it WILL print "5" every time the "a" variable contains 5.  It
> WILL do that.  As in, it's NOT a random process.
>
> >> int a;
> >> printf("a == %d\n", a);
> >>
> >> That's not "random," nor is it "stochastic," or even "perplexing!" for
> >> that matter.  It's undefined.  I can't tell you what that will print.
> >> But I can justify what it did print [if that makes any sense...].
> >>
> >> Tom
> >>
> >
> > It's not a "functional programming", it's an "imperative programming",
> > they are different.
> >
> ?
>
> Use terminology from the standard if you're going to use anything.  What
> I wrote is a syntactically correct program (hence it compiles).  It's
> just not going to produce a defined behaviour (since a is uninitialized).
>
> Here is your homework list of words to learn
>
> - undefined
> - defined
> - behaviour
> - deterministic
> - initialized [and uninitialized]
>
> I understand that English is likely not your first language, but please
> stop trying to invent new terminology.  Explain what you mean in simple
> English, and we can help you explain it in terminology prescribed by the
> standards.
>
> Tom
>

Puffff, pufff, pufff, ... my language is simple but vulgar.

Dear cryptographer Tom St Denis, you want not to understand
the simple game of russian roulette.

Here there is a demo "ishootyou.c", compile it as it says with gcc
4.1, 4.2 or 4.3
and explain me how is 'undefined' the shooting to you? Hehehehe. I jokes you ;)

#include <stdio.h>
#include <string.h>
#include <math.h>
/* It's a security's demonstration of russian roulette. */
/* The uninitialized variable decides to shoot you or not. */
/* The GCC's Warn can't avoid it shoots you. GCC's Error aborts it. */
/* For large projects, it's a big problem to avoid this play,
 *   to imagine that there is a backdoor inside because of this. */
/*        gcc -lm -Wall ishootyou.c -o ishootyou          */
/*        for i in $(seq 1 8); do ./ishootyou ; done      */
int main(int argc, char* argv[]) {
   int uninitialized_var_gurka, yes_or_not;

   if (strcmp(argv[0],"Xshootsyou")==0) uninitialized_var_gurka=0;

   yes_or_not = (((int)(sin(uninitialized_var_gurka)*(double)((unsigned)-1))
                 >> 8) & 1);

   if (yes_or_not) printf("PUM! I shooted you!\n");
   else            printf("You free.\n");

   return 0;
}

$ gcc -lm -Wall ishootyou.c -o ishootyou
$ for i in $(seq 1 8); do ./ishootyou ; done
PUM! I shooted you!
You free.
You free.
You free.
You free.
PUM! I shooted you!
You free.
PUM! I shooted you!
$

   J.C.Pizarro, sincerely, don't fear, i never did touch a gun.

Re: Missing warning about uninitialized variable.

[John Love-Jensen]

Hi J.C.,

In your ishootyou.c, if your objective is to have the compiler display the
warning, ala...

gcc -O -Wuninitialized -lm -Wall ishootyou.c -o ishootyou

ishootyou.c:12: warning: 'uninitialized_var_gurka' may be used uninitialized
in this function

...how come you are not enabling the warning, as I've done above?

Or even more so, as indicated by the comment in the code, treating it as an
error?

gcc -Werror -O -Wuninitialized -lm -Wall ishootyou.c -o ishootyou

On my version of GCC, I realize that -Wall enables -Wuninitialized ... but
ONLY if optimizations are enabled.  Which has already been mentioned by
someone else in this discussion thread.

Sincerely,
--Eljay

RE: Missing warning about uninitialized variable.

[Mikael Vidstedt]

I still haven't seen anybody comment on why that warning isn't displayed
with the latest GCC versions, no matter how many extra parameters you give
it?

I cannot - no matter how I try - make GCC print a warning for the relatively
simple case:

void func(void) {
   int i;
   if(some-condition)
      i = 1;
   use(i);
}

If I compile this with "-O -Wall -Wuninitialized" I still get _no_ warning.

/Mikael

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of John Love-Jensen
Sent: den 29 november 2007 22:30
To: J.C. Pizarro; MSX to GCC
Subject: Re: Missing warning about uninitialized variable.

Hi J.C.,

In your ishootyou.c, if your objective is to have the compiler display the
warning, ala...

gcc -O -Wuninitialized -lm -Wall ishootyou.c -o ishootyou

ishootyou.c:12: warning: 'uninitialized_var_gurka' may be used uninitialized
in this function

...how come you are not enabling the warning, as I've done above?

Or even more so, as indicated by the comment in the code, treating it as an
error?

gcc -Werror -O -Wuninitialized -lm -Wall ishootyou.c -o ishootyou

On my version of GCC, I realize that -Wall enables -Wuninitialized ... but
ONLY if optimizations are enabled.  Which has already been mentioned by
someone else in this discussion thread.

Sincerely,
--Eljay

Re: Missing warning about uninitialized variable.

[J.C. Pizarro]

On 2007/11/29, John Love-Jensen <eljay@adobe.com> wrote:
> Hi J.C.,
>
> In your ishootyou.c, if your objective is to have the compiler display the
> warning, ala...
>
> gcc -O -Wuninitialized -lm -Wall ishootyou.c -o ishootyou
>
> ishootyou.c:12: warning: 'uninitialized_var_gurka' may be used uninitialized
> in this function
>
> ...how come you are not enabling the warning, as I've done above?
>
> Or even more so, as indicated by the comment in the code, treating it as an
> error?
>
> gcc -Werror -O -Wuninitialized -lm -Wall ishootyou.c -o ishootyou
>
> On my version of GCC, I realize that -Wall enables -Wuninitialized ... but
> ONLY if optimizations are enabled.  Which has already been mentioned by
> someone else in this discussion thread.
>
> Sincerely,
> --Eljay

Put -Werror -Wuninitialized -Wall to one large project that has many warnings,
and it will be tedious to abort the entire project at the first warning!!!

To ignore -Werror is not a solution.

The solution is to implement -Werror-uninitialized. Agree we it?

   J.C.Pizarro

Re: Missing warning about uninitialized variable.

[Tony Wetmore]

Mikael Vidstedt wrote:
 > I still haven't seen anybody comment on why that warning
 > isn't displayed with the latest GCC versions, no matter
 > how many extra parameters you give it?

Mikael,

I'm afraid that your thread has been effectively hijacked.

Your problem sounds like a bug to me.  By searching the GCC bug database 
for "uninitialized warning", I found the following bugs that sound 
suspiciously similar to yours:

   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22456
   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501

These bugs were opened as regression failures for GCC 4.1, 4.2 and 4.3.

There is some discussion in the comments about whether or not the bug is 
fixable, and when it might (or might not) be fixed.

Hope this helps.

-Tony

Re: Missing warning about uninitialized variable

[Ian Lance Taylor]

David Sveningsson <ext@sidvind.com> writes:

> Hi, I recently ran into an issue with an uninitialized pointer which I
> expected g++ to warn about.
>
> class Foo {
> public:
>         Foo* a(){ return this; }
> };
>
> int main(int argc, const char*[] ){
>         for ( int i = 0; i < 6; i++ ){
>                 Foo* foo = foo->a();
>         }
> }
>
> This code compiles without any warnings (with -Wall) with both
> g++-4.4.2 and g++-4.2.4. Removing the for-loop gives me a warning as
> expected:
>
> foo.cpp: In function ‘int main(int, const char**)’:
> foo.cpp:8: warning: ‘foo’ is used uninitialized in this function
>
> I know this case is a bit silly but it happened because of a typo and
> went unnoticed for a while.
>
> Is my reasoning flawed or should g++ emit a warning?

You may get a warning with -Winit-self.

However, this sounds like a bug either way.  Please consider filing a
bug report as described at http://gcc.gnu.org/bugs/ .

Ian

Missing warning about uninitialized variable

[David Sveningsson]

Hi, I recently ran into an issue with an uninitialized pointer which I 
expected g++ to warn about.

class Foo {
public:
         Foo* a(){ return this; }
};

int main(int argc, const char*[] ){
         for ( int i = 0; i < 6; i++ ){
                 Foo* foo = foo->a();
         }
}

This code compiles without any warnings (with -Wall) with both g++-4.4.2 
and g++-4.2.4. Removing the for-loop gives me a warning as expected:

foo.cpp: In function ‘int main(int, const char**)’:
foo.cpp:8: warning: ‘foo’ is used uninitialized in this function

I know this case is a bit silly but it happened because of a typo and 
went unnoticed for a while.

Is my reasoning flawed or should g++ emit a warning?

Re: Missing warning about uninitialized variable

[Ian Lance Taylor]

Mikael Vidstedt <mikael.vidstedt@bea.com> writes:

> The following program may make use of an uninitialized variable (gurka):
> 
> int
> main(int argc, char* argv[])
> {
>    int gurka;
> 
>    if(argc == 10) {
>       gurka = 3;
>    }
> 
>    // gurka isn't necessarily initialized here...
>    printf("%d\n", gurka);
> 
>    return 0;
> }
> 
> GCC 4.0 will give a warning when this program is compiled with "-O
> -Wall". GCC 4.1 and 4.2 do not give that warning. I haven't had the
> possibility to try GCC 4.3.
> 
> What say ye?

Sounds like a bug.  Please report it according to
http://gcc.gnu.org/bugs.html.  Thanks.

Ian

Missing warning about uninitialized variable

[Mikael Vidstedt]

The following program may make use of an uninitialized variable (gurka):

int
main(int argc, char* argv[])
{
   int gurka;

   if(argc == 10) {
      gurka = 3;
   }

   // gurka isn't necessarily initialized here...
   printf("%d\n", gurka);

   return 0;
}

GCC 4.0 will give a warning when this program is compiled with "-O
-Wall". GCC 4.1 and 4.2 do not give that warning. I haven't had the
possibility to try GCC 4.3.

What say ye?

Thanks,
Mikael


# gcc-4.0 --version
gcc-4.0 (GCC) 4.0.4 20060904 (prerelease) (Debian 4.0.3-7)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

# gcc-4.0 -O -Wall -o foo foo.c
foo.c: In function 'main':
foo.c:6: warning: 'gurka' may be used uninitialized in this function
#


# gcc-4.1 --version
gcc-4.1 (GCC) 4.1.3 20071019 (prerelease) (Debian 4.1.2-17)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

# gcc-4.1 -O -Wall -o foo foo.c
#


# gcc-4.2 --version
gcc-4.2 (GCC) 4.2.3 20071014 (prerelease) (Debian 4.2.2-3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

# gcc-4.2 -O -Wall -o foo foo.c
#