[Python-Dev] Compiler warnings

Thomas Wouters thomas at xs4all.net
Wed Feb 1 15:33:22 CET 2006


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.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


More information about the Python-Dev mailing list