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.