[Python-Dev] Compiler warnings on Solaris

Thomas Wouters thomas@xs4all.net
Sat, 4 Nov 2000 14:54:17 +0100


On Sat, Nov 04, 2000 at 02:07:43AM -0500, Tim Peters wrote:
> [Greg Ward]
> > ...
> > Also, if there are warnings we're not going to worry about (eg.
> > incorrect "might be used uninitialized"), lemme know.

> If a compiler is afraid something might be uninitialized, the code is too
> clever for people to be sure it's correct at a glance too.

> I'm not sure what gcc is complaining about in many of the cases; others are
> quite clear (e.g., "confstr" apparently has no prototype in scope by the
> time it's called in posixmodule.c, and that is indeed not good).

There are a few messages that certainly should be looked at. The
'uninitialized usage' messages, for instances, might seriously be problems.
In this case, though, the "'ord' might be used uninitialized" warning isn't
a real problem. 'ord' is indeed only set when 'size == 1' is true, but it's
also only used if 'size == 1', and size isn't changed inbetween those
checks. Whether it should be fixed or not is another issue, but at least
it isn't causing problems.

The 'subscript has type char' message I'm not so sure about -- what is the
problem with those ? I assume it has something to do with char's signedness
being undefined, but I'm not sure. I also thought 'up'casting, such as in
functioncalls (function needs int, you give it char) was done automatically,
as part of the language, and thus shouldn't be a problem.

But the -Wstrict-prototypes seems to detect a lot more 'errors' in system
headerfiles than in Python. For instance, all the "function declaration
isn't a prototype" warnings in signalmodule.c and intrcheck.c seem to be
caused by the SIG_ERR, SIG_DFL and SIG_IGN #defines, which Python can do
nothing about. (those SIG_ #defines are apparently defined as function
declarations without prototypes.) I've seen the same effect on BSDI 4.0.1,
where a few system include files define or declare functions without
prototypes. We can't fix those errors, except by complaining to the OS
vendor. Maybe we should just disable -Wstrict-prototypes (but not -Wall) for
releases, to avoid confusion. (Developers should still use
-Wstrict-prototypes, to catch warnings Python *can* do something about, me
thinks.)

And the 'confstr' message, well, ewww ;) The manpage on Linux seems to
indicate you need to define either _POSIX_C_SOURCE as 2, or define
_XOPEN_SOURCE, for it to work. But I've never understood how those defines
are supposed to interact, so I'm hesitant to go there ;P

-- 
Thomas Wouters <thomas@xs4all.net>

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