X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Mon, 30 Nov 2009 18:47:56 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: getopt bugs
Message-ID: <20091130174756.GA30043@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <loom DOT 20091130T173232-79 AT post DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <loom.20091130T173232-79@post.gmane.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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