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!
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