[Python-Dev] Re: getopt() prototype [was: checkin-message of something or other]

[Thomas Wouters]

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!