[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141206174710.GY4574@brightrain.aerifal.cx>
Date: Sat, 6 Dec 2014 12:47:10 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: getopt_long permutation algorithm questions
On Thu, Dec 04, 2014 at 08:25:06AM +0200, Timo Teras wrote:
> Not sure if there's some nasty corner case surprises, but I'd start
> with that as it's the simple approach.
There is one nasty corner case I don't know how to deal with. Consider
an option string of "ab:" with the command line:
./a.out foo -ab
The "desired" result is that -a is accepted successfully and -b yields
an error due to missing argument. But permuting "-ab" before "foo"
results in "foo" being treated as the argument to -b.
Fortunately this issue only matters for erroneous (syntactically
invalid) command lines, so we can probably ignore it by just refusing
to permute them (thus simply treating "foo" and "-ab" as non-option
arguments).
Empirically (I haven't RTFS'd and don't intend to) glibc has an
alternate approach where permutation happens after the argv[]
component has been consumed rather than before. When it sees a
non-option argument, it saves the location, jumps forward and
processes the next option-containing argument, and only moves it back
to the saved location when advancing optind. This exposes nonsensical
values of optind to the application; after processing the above and
getting the error for -b, optind points to the null pointer slot at
the end of argv[], and only jumps back to point to the permuted foo
when getopt[_long] is called _again_ after the error.
I haven't yet tested what the BSD version does.
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.
