On Wed, Feb 01, 2006 at 01:51:03PM +0000, Michael Hudson wrote: > Scott Dial <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com