[Python-Dev] Compiler warnings
scott+python-dev at scottdial.com
Wed Feb 1 16:17:26 CET 2006
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
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.
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 at scottdial.com
dialsa at rose-hulman.edu
More information about the Python-Dev