[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140726093140.GM4038@brightrain.aerifal.cx>
Date: Sat, 26 Jul 2014 05:31:40 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: More GNU semantics for getopt_long?
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).
> 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.
> 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.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
