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.