From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5625 Path: news.gmane.org!not-for-mail From: Felix Janda Newsgroups: gmane.linux.lib.musl.general Subject: Re: More GNU semantics for getopt_long? Date: Sat, 26 Jul 2014 19:48:30 +0200 Message-ID: <20140726174730.GA11205@euler> References: <20140726091236.GA6011@euler> <20140726093140.GM4038@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 1406396969 26856 80.91.229.3 (26 Jul 2014 17:49:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Jul 2014 17:49:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5630-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 26 19:49:22 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 1XB65x-0002s8-L3 for gllmg-musl@plane.gmane.org; Sat, 26 Jul 2014 19:49:21 +0200 Original-Received: (qmail 5563 invoked by uid 550); 26 Jul 2014 17:49:21 -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 5554 invoked from network); 26 Jul 2014 17:49:21 -0000 X-Virus-Scanned: amavisd-new at posteo.de Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20140726093140.GM4038@brightrain.aerifal.cx> User-Agent: Mutt/1.5.22 (2013-10-16) Xref: news.gmane.org gmane.linux.lib.musl.general:5625 Archived-At: 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. > > differently than for everyone else. In particular, this breaks the > > (git) wine build itself, since its generated Makefiles call widl with > > mixed option and non-option arguments. > > > > Should wine use a (runtime) config test detecting whether > > getopt_long() does argument reordering and use its internal copy of > > getopt_long() if not? Should the Makefile generation be carefully > > rewritten such that non-options are given last? > > I'm not a fan of the misordered options/non-option-arguments, so I'd > recommend "fixing" that in the Makefile even if musl's behavior > changes. Note that the build process probably breaks if the user has > POSIXLY_CORRECT set in their environment since this turns off the GNU > reordering in glibc. Good, I have a patch for their Makefile generation. Thanks for pointing out that the build should also break for others when POSIXLY_CORRECT is set. > > It seems difficult to upstream any of these. The config test > > seems like a test specific to exclude musl and the second is > > likely to break in the future and who knows what scripts might > > depend on the argument reordering of widl. > > > > > > No abbreviations: > > Oh, there was a patch submitted for this one, and I thought I > remembered applying it, but perhaps not. I'll go back and look. There > might have still been some open issues with it to be resolved before > applying. > > > I noticed that there is a patch from Michael Forney on the mailing > > list implementing the abbreviated options but there were not any > > comments on it. > > Yes that's it. Thanks for revisiting the patch. Felix