Mail Archives: cygwin/2009/11/30/14:14:54
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
- Raw text -