[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141204082506.7e646c91@vostro>
Date: Thu, 4 Dec 2014 08:25:06 +0200
From: Timo Teras <timo.teras@....fi>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: getopt_long permutation algorithm questions
On Wed, 3 Dec 2014 19:04:34 -0500
Rich Felker <dalias@...c.org> wrote:
> On Wed, Dec 03, 2014 at 09:47:53PM +0100, Jens Gustedt wrote:
> > Am Mittwoch, den 03.12.2014, 14:56 -0500 schrieb Rich Felker:
> > > On Wed, Dec 03, 2014 at 08:43:09PM +0100, Jens Gustedt wrote:
> > > 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).
> >
> > My idea was just to do a first pass for the "real" argument
> > processing and to note during that pass if an argument wasn't used.
> > Then in a second pass reorder argv with that information.
>
> I don't think you want to pre-process the whole argument list, for
> various reasons. The GNU version, as I understand, does argument
> permutation as it goes based on the state of the opt* vars rather than
> permuting everything at once, and presumably some callers could rely
> on this, for example as a way of conditionally suppressing the
> permutation by incrementing optind rather than calling getopt when
> optind points to a non-option argument.
>
> It's also just a more complicated design and not compatible with the
> existing design/implementation of getopt[_long] to preprocess
> everything.
As reference the relevant part from man-pages is:
By default, getopt() permutes the contents of argv as it scans,
so that eventually all the nonoptions are at the end. Two other
modes are also implemented. If the first character of
optstring is '+' or the envi- ronment variable POSIXLY_CORRECT
is set, then option processing stops as soon as a nonoption
argument is encountered. If the first character of optstring is
'-', then each nonoption argv-element is handled as if it were
the argument of an option with character code 1. (This is used
by programs that were written to expect options and other
argv-elements in any order and that care about the ordering of
the two.) The special argument "--" forces an end of
option-scanning regardless of the scan- ning mode.
So it seems permutation should be done incrementally, not as one big
reorder everything operation. Though the wording allows some
interpretation freedom too.
But what Rich suggested as first, would have been my approach too. I'm
slightly confused by the complexity of permute_args() in the BSD version
we currently use for Alpine (just grabbed it as it was the first
working and BSD licensed version of the function I could find).
Not sure if there's some nasty corner case surprises, but I'd start
with that as it's the simple approach.
Thanks,
Timo
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.
