From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6685 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.linux.distributions.alpine.devel Subject: Re: getopt_long permutation algorithm questions Date: Sat, 6 Dec 2014 14:22:26 -0500 Message-ID: <20141206192226.GZ4574@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> <20141206174710.GY4574@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 X-Trace: ger.gmane.org 1417893767 2993 80.91.229.3 (6 Dec 2014 19:22:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Dec 2014 19:22:47 +0000 (UTC) Cc: alpine-devel@lists.alpinelinux.org To: musl@lists.openwall.com Original-X-From: musl-return-6698-gllmg-musl=m.gmane.org@lists.openwall.com Sat Dec 06 20:22:41 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 1XxKwD-0005bO-7x for gllmg-musl@m.gmane.org; Sat, 06 Dec 2014 20:22:41 +0100 Original-Received: (qmail 9453 invoked by uid 550); 6 Dec 2014 19:22:39 -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 9443 invoked from network); 6 Dec 2014 19:22:39 -0000 Content-Disposition: inline In-Reply-To: <20141206174710.GY4574@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6685 gmane.linux.distributions.alpine.devel:2686 Archived-At: On Sat, Dec 06, 2014 at 12:47:10PM -0500, Rich Felker wrote: > 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. The BSD code Alpine is using right now seems to do the same thing as glibc does empirically, and the implementation matches what I expected -- saving state and applying the permutation later. My leaning is still to go with the method I proposed that avoids internal state and inconsistent values of optind during parsing, at the expense of not permuting syntactically invalid command lines. Any opinions? BTW just a heads-up for Alpine: the BSD code that's being patched in right now contains namespace violations and is causing code linked to their modified libc to contain copy-reloc references to optreset rather than __optreset, if it uses optreset. I think this will be safe to fix (old binaries will continue to work once it's fixed), but it's not forwards compatible. Binaries built with the correct symbol name (again, only programs which use optreset) will not work on Alpine's old libc.so, so upgrading libc will be mandatory to use new binaries. This also applies to binaries build against musl on non-Alpine systems and carried over to Alpine. Rich