Re: Suspicious warning in W64 build

[Paul Eggert <eggert@cs.ucla.edu>]

Andy Moreton wrote:
> the whole idea of UNINIT is dubious, and invites overly clever
> compilers to exploit undefined behaviour in the name of optimisation,
> and emit broken code that does not meet the expectations of the
> programmer.

There's no such invitation, as UNINIT is used only when GCC incorrectly warns 
about variables being uninitialized. Although undefined behavior would occur if 
the variables were used before initialization, they are not used that way. 
Clever compilers cannot exploit undefined behavior that does not exist.

These glitches arise because GCC does not warn only when it can prove that an 
variable will be used before being initialized (as that wouldn't be all that 
useful). Instead, GCC uses not-completely-reliable heuristics that sometimes 
result in false positives. Although GCC cannot exploit these heuristics to 
optimize code (because in general code optimized via unreliable heuristics might 
behave incorrectly), GCC can use these heuristics to generate warnings (because 
false-positive warnings are an acceptable price to pay if they're rare enough 
and if the correct warnings are useful enough).

UNINIT is not the only macro used to pacify GCC, by the way. There is also 
CACHEABLE, and I think others.

> If the compiler complains about an uninitialised use, then fix the code to
> initialise the variable and remove the UB rather than disguising it with
> an UNINIT macro.

The code is not broken, and if "fixing" it makes it worse then we should leave 
it alone. The main goal here is to write clear and correct and efficient code; 
pacifying false positives is secondary.