Re: More GNU semantics for getopt_long?

[Rich Felker <dalias@libc.org>]

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