On Thu, Oct 12, 2000 at 05:38:13PM -0400, Tim Peters wrote:
[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.
Ah, that sounds about right. Nifty link, too. I thought it had something to do with the prototype because of this comment: CONFORMING TO getopt(): POSIX.2, provided the environment variable POSIXLY_CORRECT is set. Otherwise, the elements of argv aren't really const, because we permute them. We pretend they're const in the prototype to be compatible with other systems.
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 [ a lot of things ]
Ahh, yes, I see Python/getopt.c and the autoconf check that enables it when necessary. Funny, I've seen that file a number of times, and read it, and read the getopt autoconf test as well, but somehow I never connected it with the loose prototype in main.c. I'm +1 on doing what you suggested, then. Wonder why it hasn't been done yet, though... we have no use for a system-wide getopt, except for a slightly smaller binary on systems that do have a 'good' system getopt. We can't use enhancements made to system getopt or anything, anyway.
they've-had-21-years-to-straighten-out-"the-std"-getopt-and-they-blew-it- ly y'rs - tim
what-do-you-want-to-bet-it's-going-to-take-longer-for-Python-getopt-modules- ly y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!