Re: getopt_long permutation algorithm questions

[Timo Teras <timo.teras@iki.fi>]

On Wed, 3 Dec 2014 19:04:34 -0500
Rich Felker <dalias@libc.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