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

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 initbuiltin(char *name) { struct inittab *p; PyObject *mod; if ((mod = PyImportFindExtension(name, name)) != NULL) return 1; to this: static int initbuiltin(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.