To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: getopt bugs
Date: Mon, 30 Nov 2009 19:14:24 +0000 (UTC)
Lines: 78
Message-ID:  <loom.20091130T194900-224@post.gmane.org>
References:  <loom DOT 20091130T173232-79 AT post DOT gmane DOT org> <20091130174756 DOT GA30043 AT calimero DOT vinschen DOT de>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
User-Agent: Loom/3.14 (http://gmane.org/)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Corinna Vinschen <corinna-cygwin <at> cygwin.com> 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 
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.

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 
POSIXLY_CORRECT is set.

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

[1] See these posts and others in the same thread:
 http://lists.gnu.org/archive/html/bug-m4/2006-09/msg00009.html
 http://lists.gnu.org/archive/html/bug-m4/2006-09/msg00018.html
 http://lists.gnu.org/archive/html/bug-m4/2006-09/msg00028.html
 http://lists.gnu.org/archive/html/bug-m4/2006-09/msg00034.html
 http://lists.gnu.org/archive/html/bug-m4/2006-09/msg00035.html

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

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