Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 25 Nov 2014 02:39:32 -0500
From: Rich Felker <>
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.


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.