This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

getopt bugs


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.

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.

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 (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.

Here's an example of how the m4 testsuite caught this second bug (by the way, 
m4 is one of the few exceptions explicitly mentioned in POSIX where options 
must be parsed interspersed with file names, rather than the normal rule that 
options stop on the first non-option):

On Linux or cygwin 1.5 (where there were enough other getopt bugs that m4 used 
the glibc getopt):
$ echo foo > bar
$ m4 -Dfoo=1 bar -Dfoo=2 bar
1
2
$ POSIXLY_CORRECT= m4 -Dfoo=1 bar -Dfoo=2 bar
1
2

On cygwin 1.7 (where m4 tried to use cygwin's native getopt)
$ echo foo > bar
$ m4 -Dfoo=1 bar -Dfoo=2 bar
1
2
$ POSIXLY_CORRECT= m4 -Dfoo=1 bar -Dfoo=2 bar
m4: cannot open `-Dfoo=2': No such file or directory

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.  But it does seem rather ironic that setting POSIXLY_CORRECT actually 
breaks POSIX compliance of m4 argument parsing.

-- 
Eric Blake



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]