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 > testsuite.
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 correct. > (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 > report. 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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple