On Thu, Oct 12, 2000 at 10:11:41AM -0700, Fred L. Drake wrote: [ use -Wall and -Wstrict-prototypes by default, if the compiler is gcc ]
There is one known warning at this time, caught by the -Wstrict-prototypes option. In Modules/main.c, the declaration of getopt() without parameters gets a complaint (rightly) that it is not a proper prototype. The lack of a complete prototype information should be corrected when the right portability conditions have been identified.
I already looked at this before, and the problem is that the prototype for getopt is not portable (because of quirks in the ANSI C standard regarding 'compatible' pointer types.) Some systems define it as 'const char **' (or 'char const **'), some perhaps as 'char **', and some as 'char * const *'. 'const char **' and 'char const **' are the same, but 'char * const *' is something else, and so is 'char **'. 'char * const *' and 'char **' are equivalent types, meaning that conforming compilers should be able to intermix them without problems, but 'const char **' is a different type, and ANSI C either demands or strongly suggests a warning. (Why exactly it's a different type is mostly a choice of language, though I'm sure there are people who would defend the choice. What it means it that you can't mix two layers of indirection with qualifiers like 'const' or 'volatile', without paying close attention to assignment and prototypes :P) As a result, no matter what prototype we think up, we're always screwing either the one type of platform or the other. And not with a warning; the conflicting prototype would generate an error, nto a warning. The only solution I can think of is adding the proper prototype to the pyport.h header file, inside a proper #ifdef. For generated code it doesn't really matter which of the prototypes is used, but if the system headers do provide a prototype, and it doesn't match in indirect-constness, compilation will fail. (In other words, even on the platforms that are missing it, close attention should be paid to the manual pages, trying to guess what the prototype is going to look like if that particular system would ever grow a prototype in a system header. From what I read in the getopt(3) manpage on my linux box the prototype mixup comes from a POSIX.2 flaw, but I'm not sure.) Does anyone have a system where the prototype to getopt() is not defined in header files ? My Solaris 2.x testbox has that problem, but the box in question is one huge mess, and I doubt it has anything to do with Solaris in particular. I only use it to reproduce reported bugs, not report any myself ;P -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!