From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6678 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: getopt_long permutation algorithm questions Date: Wed, 3 Dec 2014 14:56:08 -0500 Message-ID: <20141203195608.GM4574@brightrain.aerifal.cx> References: <20141203192929.GA14223@brightrain.aerifal.cx> <1417635789.4789.35.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1417636594 29274 80.91.229.3 (3 Dec 2014 19:56:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Dec 2014 19:56:34 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6691-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 03 20:56: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 1XwG2B-0006ui-O6 for gllmg-musl@m.gmane.org; Wed, 03 Dec 2014 20:56:23 +0100 Original-Received: (qmail 24030 invoked by uid 550); 3 Dec 2014 19:56:22 -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 24021 invoked from network); 3 Dec 2014 19:56:21 -0000 Content-Disposition: inline In-Reply-To: <1417635789.4789.35.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6678 Archived-At: 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