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.