From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5627 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: More GNU semantics for getopt_long? Date: Sat, 26 Jul 2014 14:34:13 -0400 Message-ID: <20140726183413.GO4038@brightrain.aerifal.cx> References: <20140726091236.GA6011@euler> <20140726093140.GM4038@brightrain.aerifal.cx> <20140726174730.GA11205@euler> 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 1406399674 24425 80.91.229.3 (26 Jul 2014 18:34:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Jul 2014 18:34:34 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5632-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 26 20:34:26 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XB6na-0001tA-FO for gllmg-musl@plane.gmane.org; Sat, 26 Jul 2014 20:34:26 +0200 Original-Received: (qmail 3537 invoked by uid 550); 26 Jul 2014 18:34:25 -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 3529 invoked from network); 26 Jul 2014 18:34:25 -0000 Content-Disposition: inline In-Reply-To: <20140726174730.GA11205@euler> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5627 Archived-At: On Sat, Jul 26, 2014 at 07:48:30PM +0200, Felix Janda wrote: > Rich Felker wrote: > > On Sat, Jul 26, 2014 at 11:12:36AM +0200, Felix Janda wrote: > > > I have had two problems with the fact that musl's getopt_long() does > > > not behave as applications expect. > > > > > > > > > No argument reordering: > > > > > > musl's getopt_long() behaves similarly to POSIX getopt() and therefore > > > stops after the first non-option argument. This for example makes the > > > utilities widl and wrc from wine when compiled with musl libc behave > > > > This has been discussed a few times and could possibly be changed. > > Some consideration is needed for whether it leads to problematic > > inconsistency between getopt and getopt_long, but I don't think so. > > The worst part is that it makes it impossible to get conforming > > behavior from GNU coreutils since there would be no way to override > > the reordering (whereas, if they replace getopt_long with their own > > version, it can be overridden by setting the POSIXLY_CORRECT > > environment variable). > > The BSDs seem to have this inconsistency between getopt and getopt_long > as well. Their getopt_long also respects POSIXLY_CORRECT, though. This > is IMO something musl should do as well when possibly introducing the > reordering of arguments in future. Yes, that may be reasonable. Since getopt_long is not standard anyway there's no reason it has to avoid reading the environment. For standard functions, they can't read the environment unless they're specified to because doing so introduces a usage limitation (they can't be called when the environment could be being modified); glibc's getopt doing so is a bug, I think. Rich