On Fri, Jun 22, 2007 at 06:59:02PM +0200, Alan Barrett wrote:
> On Thu, 21 Jun 2007, Brian Ginsbach wrote:
> > I'd like to make the following change to getopt_long(3).  The
> > current NetBSD version of getopt_long(3) does not match the behavior
> > of GNU getopt_long(3) when dealing with potentially abmiguous
> > arguments.
> 
> Could you explain this in a way that doesn't require the reader to
> reverse engineer the patch?  What is a "potentially ambiguous argument",
> and what are the two behaviours?
> 

OK, I'll try.

Here is the test from the GNU C library for getopt_long(3):

The long options are set so that both "color" and "colour" would
be supported and both return the same value when parsed.  There
are no other long options that start with "col".

A command is passed the option --col.  The current version of NetBSD
getopt_long(3) treats this as an ambiguous argument.  This was the
behavior of GNU getopt_long(3) for GNU C library 2.1.3.  Later
versions of the GNU C library doesn't treat this as ambiguous.

The change also fixes the handling of single character options that
are both a long option and a short option and there are options
that start with the same character.  Note the long option parses
to a different value than the short option.

The example I came across was in trueprint.  It has both "f"
(long option) and 'f' (short option) along with "form-feeds",
"footers", "four-up", "file-index", and "function-index".  The
NetBSD version returns '?' for '--f'.  The GNU version returns the
value associated with '--f'.

I hope this is helps.