[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