getopt_long incompatibility

getopt_long incompatibility

[Michael Forney]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

Hi,

I noticed when building gzip with musl that gnulib is still replacing
getopt and getopt_long. After some investigation, it looks to be because
it expects getopt_long to accept ambiguous options with the same
has_arg, flag, and val values[0].

The code responsible for this seems to only do this for getopt_long and
not getopt_long_only[1]. I have no idea why, but since musl aims to
conform to glibc's getopt_long behavior, we should probably do the same.

[0] http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/getopt.m4#n313
[1] http://sourceware.org/git/?p=glibc.git;a=blob;f=posix/getopt.c;hb=HEAD#l562

-- 
Michael Forney <mforney@mforney.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: getopt_long incompatibility

[Rich Felker]

On Sun, Apr 26, 2015 at 11:24:32PM -0700, Michael Forney wrote:
> Hi,
> 
> I noticed when building gzip with musl that gnulib is still replacing
> getopt and getopt_long. After some investigation, it looks to be because
> it expects getopt_long to accept ambiguous options with the same
> has_arg, flag, and val values[0].
> 
> The code responsible for this seems to only do this for getopt_long and
> not getopt_long_only[1]. I have no idea why, but since musl aims to
> conform to glibc's getopt_long behavior, we should probably do the same.
> 
> [0] http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/getopt.m4#n313
> [1] http://sourceware.org/git/?p=glibc.git;a=blob;f=posix/getopt.c;hb=HEAD#l562

I read the gnulib code but I don't see why it expects a match. From
the glibc code it looks to me like the ambig_list should have length 2
and produce an error. I don't see any reasonable way getopt_long could
choose between the two choices for the user without violating a
principle of least surprise. Do you get what's going on?

Rich

Re: getopt_long incompatibility

[Michael Forney]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

On Mon, Apr 27, 2015 at 12:18:16PM -0400, Rich Felker wrote:
> I read the gnulib code but I don't see why it expects a match. From
> the glibc code it looks to me like the ambig_list should have length 2
> and produce an error. I don't see any reasonable way getopt_long could
> choose between the two choices for the user without violating a
> principle of least surprise. Do you get what's going on?
> 
> Rich

glibc only adds to ambig_list if the following condition is met:

    if (long_only
        || pfound->has_arg != p->has_arg
        || pfound->flag != p->flag
        || pfound->val != p->val)

so I guess if all the matching option structs are the same, you're
allowed to pick any matching option for longindex (unless you're in
getopt_long_only).

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: getopt_long incompatibility

[Rich Felker]

On Mon, Apr 27, 2015 at 09:56:53AM -0700, Michael Forney wrote:
> On Mon, Apr 27, 2015 at 12:18:16PM -0400, Rich Felker wrote:
> > I read the gnulib code but I don't see why it expects a match. From
> > the glibc code it looks to me like the ambig_list should have length 2
> > and produce an error. I don't see any reasonable way getopt_long could
> > choose between the two choices for the user without violating a
> > principle of least surprise. Do you get what's going on?
> > 
> > Rich
> 
> glibc only adds to ambig_list if the following condition is met:
> 
>     if (long_only
>         || pfound->has_arg != p->has_arg
>         || pfound->flag != p->flag
>         || pfound->val != p->val)
> 
> so I guess if all the matching option structs are the same, you're
> allowed to pick any matching option for longindex (unless you're in
> getopt_long_only).

OK, I think this behavior could be allowed. Seems useless but
harmless. I'll look at what it takes to implement it.

Rich