Am Sonntag, den 16.06.2013, 09:22 +0200 schrieb Jens Gustedt:
> But then I also checked with clang, and it doesn't find this
> either. First, I thought that the control flow surrounding this must
> be fundamentally flawed if the compilers aren't capable to track such
> simple cases of uninitialized variables. But even by simplifying, it
> doesn't trigger, so I am not sure what is going on.

I checked the assembler that is produced, and the reason that the bug
might not trigger for most people is that the variable ends up in ebx
which is nulled anyway at the beginning of the function. Then,
depending on how that (static) function might be inlined or not in the
context of the calling function and in which hardware register the
variable ends up, there, this could trigger the bug or not.

In all, this re-enforces my opinion to *always* initialize variables,
unless I know that its address is immediately passed to an
initialization function. If the compiler is good in computing the flow
control for a given case, it will optimize it out if it is
superfluous. If the flow control is too complicated for the compiler,
it is probably too complicated for me, too.

BTW, I used valgrind to help me finding such stuff on initialization,
but the tons of false positives that musl triggers because of the str
functions and calloc are really a pain.

Jens

-- 
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/   ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090   ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536   ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183   ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::