This is the mail archive of the
mailing list for the Cygwin project.
Re: getopt bugs
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 30 Nov 2009 18:47:56 +0100
- Subject: Re: getopt bugs
- References: <loom.20091130T173232firstname.lastname@example.org>
- Reply-to: cygwin at cygwin dot com
On Nov 30 16:54, Eric Blake wrote:
> Cygwin 1.7 getopt has made some strides towards being more Linux-compatible,
> but there are still a couple remaining bugs recently detected by the m4
Bugs? Linux-incompatibilities, ok, but bugs?
> On Linux, setting optind=0 forces a re-evaluation of
> getenv("POSIXLY_CORRECT"); this can be useful if a program wants to
> parse multiple argv sequences, and calls either
> unsetenv("POSIXLY_CORRECT") or setenv("POSIXLY_CORRECT","",1) in
> between the two sequences. But on cygwin, the environment is
> consulted only once and cached; thereafter, there is no way to change
> the state of whether the getopt engine will attempt posix compliance.
That's still the case in the upstream OpenBSD sources.
A fix based on these sources would be simple, though.
> On Linux, there is an extension to POSIX of using "-" at the beginning
> of the optstring argument to getopt to get it to parse all arguments
> in order until an instance of "--" is encountered (with non-options
> appearing as if they were the optarg of the invisible short-opt '\1').
> Cygwin's getopt also supports this extension, but only when
> POSIXLY_CORRECT is unset
Which makes sense, given that this is a GNU extension and not POSIXly
> (and given the first bug,
> there is no way to unset the POSIXLY_CORRECT state once getopt() has been
> invoked at least once). Since a leading dash in the optstring is a pure
> extension permitted by POSIX, the state of POSIXLY_CORRECT should not disable
> the extension.
I disagree. Or rather, I agree with the BSD sources here. The in-order
scanning of the arguments should only be supported if POSIXLY_CORRECT is
not set. I don't see the special allowance for a leading dash in optstring
anywhere in the POSIX getopt man pages.
> I don't know if either of these bugs have been fixed in the upstream BSD
> sources that cygwin borrowed from, or if we also need to raise a BSD bug
It's not a bug per se. POSIX doesn't specify this behaviour so I don't
see how this qualifies as a bug. The NetBSD sources show that the
developers are aware of the fact that glibc's getopt is handling the
in-order scanning independently of POSIXLY_CORRECT, but they didn't
align the behaviour to that so far.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple