[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 Nov 2014 12:42:27 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: More GNU semantics for getopt_long?
On Mon, Jul 28, 2014 at 12:30:44AM +0200, Felix Janda wrote:
> Rich Felker wrote:
> [..]
> > > > > I noticed that there is a patch from Michael Forney on the mailing
> > > > > list implementing the abbreviated options but there were not any
> > > > > comments on it.
> > > >
> > > > Yes that's it.
> > >
> > > Thanks for revisiting the patch.
> >
> > Have you tried it and confirmed that it solves your problem and
> > doesn't introduce any bugs that you immediately notice? I'd like to
> > include it in the upcoming release but I don't want to introduce a
> > stupid regression from lack of testing...
I'd like to resume working on getting this integrated, especially
since one of the main Roadmap goals for 1.1.6 is solving the remaining
issues Alpine Linux is matching musl for, of which getopt_long is one.
> I did some tests right now. The abbreviated options seem to work.
>
> If the long option abbreviation is ambiguous, patched musl's
> getopt_long will return the last match in the longopts array instead
> of '?'.
>
> I also noticed that 66fcde4ae4a52ae3edb1cf237ce2c22d08d7a062 seems
> to have broken getopt_long: Even if optstring does not begin with
> ':', getopt_long will return ':' if a long option is not supplied
> by its required argument.
Is this still broken, and if so, could you provide a short testcase I
could use for checking it and figuring out what's wrong?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
