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

[Tim Peters]

[Thomas Wouters, on getopt]
> ...
> 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.)

I bet it's actually talking about Interpretation 150 to POSIX.2, here (while
you can't read the std online, you can read the complaints online!):

http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150.
html

Doesn't have anything to do with the prototype, alas.

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

Sure:  Windows doesn't have a getopt; getopt isn't std C (not even in C99).
Assorted derived stds demand that a getopt protoptype appear in stdlib.h,
and others that it appear in unistd.h.

I have a different suggestion:  screw it.  getopt keeps creating problems on
GNUish systems too, because without the POSIXLY_CORRECT envar set, the GNU
getopt shuffles all the "option strings" to the front, making a mess of,
e.g.,

python myprog.py -v

The Python source tree already has its own getopt implementation
(Python/getopt.c) -- let's rename its contained function to PyOS_Getopt, get
rid of the irritating __BEOS__ #ifdef'ery therein, prototype it the way we
like, and have Python use that instead on all systems.  Every second we've
spent tracking down problems with platform-supplied getopts has been a waste
of time.

they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it-
    ly y'rs  - tim