A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2001-October/017737.html below:

[Python-Dev] Fixing compiler warnings (bug #445960)

[Python-Dev] Fixing compiler warnings (bug #445960)Tim Peters tim.one@home.com
Wed, 3 Oct 2001 22:04:38 -0400
[Greg Ward]
> What's the general feeling/policy on fixing very minor problems
> that cause legitimate compiler warnings with some compilers?

If they're truly problems, they should be fixed.

> ISTR that Tim is adamant about keeping Python warning-free on Windows
> with MSVC,

Yes, but note that MSVC doesn't complain about non-problems <0.9 wink -- it
actually does, but not at the wng level we use there>.

> but what about, say, the compiler that ships with IRIX 6.5?

Doesn't have to do with the compiler so much as the specifics of what it's
complaining about.  MSVC and gcc and XXX catch different things, and that's
valuable.

> It's not a widely-used platform, but the compiler does catch some
> genuine, albeit small, problems -- mostly of the "variable set but
> never used" variety.  It looks like most fixes are along the lines of
> changing this:
>
> static int
> init_builtin(char *name)
> {
> 	struct _inittab *p;
> 	PyObject *mod;
>
> 	if ((mod = _PyImport_FindExtension(name, name)) != NULL)
> 		return 1;
>
> to this:
>
> static int
> init_builtin(char *name)
> {
> 	struct _inittab *p;

Seems to be missing a line; I assume

	if (_PImport_FindExtension(name, name) != NULL)
		return 1;

was intended.  I'd make that change, as there's no downside.

Examples of changes I wouldn't make:

1. A compiler warning when an __inline function isn't inlined.

2. A compiler complaining about a vrbl possibly used before
   initialization, when it's instantly obvious that the vrbl is
   initialized on all paths before use (got a report like that
   with two of those yesterday -- won't "fix").

3. Often (but not always) a complaint that an assignment is stomped on
   before use.  This one I'd do something about:

     a = 1;  /* complaint about this */
     a = 2;

   This one I wouldn't:

     PyObject *result = NULL;  /* complaint about this */

     /* 300 lines of excruciating code, every one of the 116 paths
        through which just happens to set result before it's used.
     */

     return result;

A special problem with #2 and #3 is that shutting up a compiler that
complains about one of them often creates code that another compiler will
complain about for the other reason.  That's one reason "no warning from any
compiler" is impossible to achieve.




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4