From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6684 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: getopt_long permutation algorithm questions Date: Sat, 6 Dec 2014 12:47:10 -0500 Message-ID: <20141206174710.GY4574@brightrain.aerifal.cx> 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> <20141204082506.7e646c91@vostro> 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 1417888051 15966 80.91.229.3 (6 Dec 2014 17:47:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Dec 2014 17:47:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6697-gllmg-musl=m.gmane.org@lists.openwall.com Sat Dec 06 18:47:25 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 1XxJS0-0003O4-UX for gllmg-musl@m.gmane.org; Sat, 06 Dec 2014 18:47:25 +0100 Original-Received: (qmail 25945 invoked by uid 550); 6 Dec 2014 17:47:23 -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 25928 invoked from network); 6 Dec 2014 17:47:23 -0000 Content-Disposition: inline In-Reply-To: <20141204082506.7e646c91@vostro> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6684 Archived-At: On Thu, Dec 04, 2014 at 08:25:06AM +0200, Timo Teras wrote: > Not sure if there's some nasty corner case surprises, but I'd start > with that as it's the simple approach. There is one nasty corner case I don't know how to deal with. Consider an option string of "ab:" with the command line: ./a.out foo -ab The "desired" result is that -a is accepted successfully and -b yields an error due to missing argument. But permuting "-ab" before "foo" results in "foo" being treated as the argument to -b. Fortunately this issue only matters for erroneous (syntactically invalid) command lines, so we can probably ignore it by just refusing to permute them (thus simply treating "foo" and "-ab" as non-option arguments). Empirically (I haven't RTFS'd and don't intend to) glibc has an alternate approach where permutation happens after the argv[] component has been consumed rather than before. When it sees a non-option argument, it saves the location, jumps forward and processes the next option-containing argument, and only moves it back to the saved location when advancing optind. This exposes nonsensical values of optind to the application; after processing the above and getting the error for -b, optind points to the null pointer slot at the end of argv[], and only jumps back to point to the permuted foo when getopt[_long] is called _again_ after the error. I haven't yet tested what the BSD version does. Rich