From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6682 Path: news.gmane.org!not-for-mail From: Timo Teras Newsgroups: gmane.linux.lib.musl.general Subject: Re: getopt_long permutation algorithm questions Date: Thu, 4 Dec 2014 08:25:06 +0200 Message-ID: <20141204082506.7e646c91@vostro> References: <20141203192929.GA14223@brightrain.aerifal.cx> <1417635789.4789.35.camel@eris.loria.fr> <20141203195608.GM4574@brightrain.aerifal.cx> <1417639673.4789.45.camel@eris.loria.fr> <20141204000434.GN4574@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1417674333 11959 80.91.229.3 (4 Dec 2014 06:25:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2014 06:25:33 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-6695-gllmg-musl=m.gmane.org@lists.openwall.com Thu Dec 04 07:25:27 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XwPqw-0005ty-Pi for gllmg-musl@m.gmane.org; Thu, 04 Dec 2014 07:25:26 +0100 Original-Received: (qmail 30010 invoked by uid 550); 4 Dec 2014 06:25:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 30002 invoked from network); 4 Dec 2014 06:25:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=qU2Ev6eSDsujkvmloBCNLbgPWYSvSyrpYz96/24I44Y=; b=sD+Ul3OApJX1O8AuBFZNbILpQjNQal9ui8KB9x3CN/Eq3wV066Mb+cCWUwZoM44mnn 11uK6nlXDEK6bC1rygfb3hDcj5M4osL4XjPCmA546vpIfS3ks+eqTNnew9xUK/NMNwFH XVEhp8hHcAEZVo8+kDNJ9D5f7s9ww6vTM2hGuOmSHWqhKAAOcSjmM+KLD9VehcvfBOMN jmTiZmWgClDvVfDSYqoEqhF6WbTYwvdd3+gUWM5ZDZfdVUNzuvHwXF/UkaKi5TrgeKsg veJ2OWJyKaOScKZHI/ftHNaX0EYPQ03B9sTwql8qiCzlnznG7KzJM8AFsVtA4bo9bIb1 vVTQ== X-Received: by 10.152.22.97 with SMTP id c1mr7608223laf.85.1417674312786; Wed, 03 Dec 2014 22:25:12 -0800 (PST) Original-Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= In-Reply-To: <20141204000434.GN4574@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.11.0 (GTK+ 2.24.23; x86_64-alpine-linux-musl) Xref: news.gmane.org gmane.linux.lib.musl.general:6682 Archived-At: On Wed, 3 Dec 2014 19:04:34 -0500 Rich Felker 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