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