[Python-Dev] Compiler warnings

[Scott Dial]

Thomas Wouters wrote:
> On Wed, Feb 01, 2006 at 01:51:03PM +0000, Michael Hudson wrote:
>> Scott Dial <scott+python-dev at scottdial.com> writes:
>>
>>> So, either the GCC people have not noticed this problem, or (more 
>>> likely) have decided that this is acceptable, but clearly it will cause 
>>> spurious warnings. Hey, after all, they are just warnings.
> 
>> Well, indeed, but "no warnings" is a useful policy -- it makes new
>> warnings much easier to spot :)
> 
>> The warnings under discussion seem rather excessive to me.
> 
> Yes, and more than that; fixing them 'properly' requires more than just
> initializing them. There is no sane default for some of those warnings, so a
> proper fix would have to check for a sane value after the function returns.
> That is, if we take the warning seriously. If we don't take it seriously,
> initializing the variable may surpress a warning in the future: one of the
> called functions could change, opening a code path that in fact doesn't
> initialize the output variable. But initializing to a sentinel value,
> checking the value before use and handling that case sanely isn't always
> easy, or efficient. Hence my suggestion to let this wait a bit (since they
> are, at this time, spurious errors). Fixing the warnings *now* won't fix any
> bugs, may mask future bugs, and may not be necessary if gcc 4.0.4 grows a
> better way to surpress these warnings. Or gcc 4.0 may grow more such
> warnings, in which case we may want to change the 'no warnings' policy or
> the flags to gcc, or add a 'known spurious warnings' checking thing to the
> buildbot.
> 

Although it is no consolation, there are two types of unused variable 
warnings: the known-error ("is used uninitialized in this function") and 
a probable-error ("may be used uninitialized in this function"). It may 
be reasonable to ignore the probable-error case. I think someone even 
mentioned that they really should be an "info" and not a "warning".

The points in the code clearly should have attention brought to them 
because there is a real possibility of error, but as you say, there is 
no way to rid yourself of this type of warning.

Also, note that the phrasing "is"/"may be" is a change from 3.x to 4.x. 
The old warning was "might" always, and as I understand gcc the "might" 
of 3.x maps directly to the "is" of 4.x -- leaving "may be" an entirely 
new thing to 4.x.

 From gcc/tree-ssa.c:
    The second pass follows PHI nodes to find uses that are potentially
    uninitialized.  In this case we can't necessarily prove that the use
    is really uninitialized.  This pass is run after most optimizations,
    so that we thread as many jumps and possible, and delete as much dead
    code as possible, in order to reduce false positives.  We also look
    again for plain uninitialized variables, since optimization may have
    changed conditionally uninitialized to unconditionally uninitialized.

-- 
Scott Dial
scott at scottdial.com
dialsa at rose-hulman.edu