[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20141125073932.GR29621@brightrain.aerifal.cx>
Date: Tue, 25 Nov 2014 02:39:32 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] getopt: add support for non-option arguments
On Tue, Nov 25, 2014 at 08:33:50AM +0100, Gianluca Anzolin wrote:
> > I'm a little bit uncertain what's really best to do with getopt_long,
> > but since there's a pending patch for abbreviated long options and
> > there's demand to add GNU-style argv permutation to getopt_long (but
> > not plain getopt), this code is likely to need major changes anyway
> > in this release cycle, so I'm not too concerned that we do it the
> > "best possible way" right now anyway. So if it works we can probably
> > go with it.
> >
>
> I tested the changes and verified that they work correctly. However I found
> something worth mentioning, not caused by the patch itself.
>
> For a command line like the following (optstring="a:b:c:def")
>
> $ ./test -a 1 -b 2 -c 3 -d -e -f
>
> for the options d, e and f the variable optarg is "3". Maybe this is the
> intended behaviour, after all those options aren't supposed to get an argument,
> but glibc always sets optarg to NULL in these cases.
This is a bug in glibc. getopt is specified to set optarg only in the
case where the option takes an argument.
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.
