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]

Re: getopt bugs

Corinna Vinschen <corinna-cygwin <at>> writes:

> Bugs?  Linux-incompatibilities, ok, but bugs?

Well, a bug is defined as operating differently than documented, and we are 
documented as striving for linux compatibility where possible.

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

POSIX explicitly states that:

"All option characters allowed by Utility Syntax Guideline 3 are allowed in 
optstring. The implementation may accept other characters as an extension."

"-" is not allowed by Utility Syntax Guideline 3.  Therefore, its use in 
optstring is an extension.  And per glibc definition (which BSD later copied), 
this particular extension means for in-order processing, regardless of 
POSIXLY_CORRECT.  BSD is wrong for not copying glibc's extension correctly when 
they followed glibc by implementing the same leading - extension.

The same goes for "+" at the start of optstring, which both glibc and BSD 
interpret as an extension to mean that posix rules of no permuting will be 
obeyed even when POSIXLY_CORRECT is not set.  The same also goes for "::" 
meaning optional argument processing, since the second ":" falls in the slot 
that POSIX requires for the next option character, but it is not a valid 
option.  But glibc and BSD honor these two extensions regardless of whether 

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

Remember, BSD recently changed their handling of "::" to match glibc with 
regards to optional argument processing, even when POSIXLY_CORRECT was set, in 
part because I complained to them[1] that they were violating cross-
compatibility to glibc, and that POSIXLY_CORRECT does not forbid "::" - the use 
of POSIXLY_CORRECT should _only_ affect behaviors which are non-compliant by 
default, rather than crippling extensions.  The use of getopt() extensions 
should allow for applications to implement POSIX requirements on option 
processing, and m4 has a POSIX requirement to process arguments in order, which 
is most easily met by the leading "-" extension.  So, if you argue that their 
change to "::" handling under POSIXLY_CORRECT was a bug fix, then you can argue 
that they should change leading "-" handling under POSIXLY_CORRECT for the same 

[1] See these posts and others in the same thread:

in particular, the FreeBSD guy stated "I see -- would you have a test-case, 
that detects this difference? Getopt_long was introduced into *BSD for the sake 
of compatibility with GNU software -- any incompatibilities in semantics are a 
bug, which should be fixed. It can not be fixed, however, if it is not 

Eric Blake

Problem reports:
Unsubscribe info:

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