[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141203195608.GM4574@brightrain.aerifal.cx>
Date: Wed, 3 Dec 2014 14:56:08 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: getopt_long permutation algorithm questions
On Wed, Dec 03, 2014 at 08:43:09PM +0100, Jens Gustedt wrote:
> Am Mittwoch, den 03.12.2014, 14:29 -0500 schrieb Rich Felker:
> > As part of resolving the rest of the dist-local changes Alpine is
> > applying to musl, I'm trying to figure out how to add GNU-style
> > argument permutation to getopt_long. The basic concept is simple: when
> > a non-option argument is encountered, skip forward until the next
> > option (argument beginning with '-') and move it (and possibly its
> > argument) before the non-option arguments. However, there are some
> > ugly corner cases like:
> >
> > arg1 -ab foo arg2
> >
> > where 'a' and 'b' are options, and 'b' takes an argument, foo. Here it
> > seems like, in order to perform the correct permutation, lookahead is
> > required to see that foo also needs to be moved. Is this correct?
> >
> > For long options, it's immediately decidable from the option being
> > processed whether it has no argument, or an argument that's part of
> > the same argv[] string, or a separate option in the next argv[] slot.
> > For short options, it seems necessary to scan each character of the
> > argv[] string to be moved, looking for the first option that takes an
> > argument. If none is found, or if such a character is found in a
> > non-final position, only this string needs to be moved. If an option
> > needing an argument is found in the final position, two argv[] strings
> > need to be moved. Is this correct?
>
> sounds all a bit complicated and fragile to me. getopt should neither
> be performance nor memory critical, so there is not much need for
> optimization here, no?
>
> Why don't you just keep track of the cases in an array on the stack,
> and then do all the moves after the processing in a second scan? You
> have argc, so you know the size of a VLA (`char[argc]` should suffice)
> that you would have to define.
I'm not trying to optimize anything for performance here, just get it
correct and simple. I don't quite understand what you're proposing,
but doing a multi-pass, out-of-place operation does not sound simple,
and it's not robust since the kernel allows huge argument lists
whereby char[argc] would overflow the stack (and even if it didn't,
assuming that it doesn't allow them would be an unwarranted assumption
unless it actually bought us some simplicity, which I don't see).
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.
