[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150427161816.GY17573@brightrain.aerifal.cx>
Date: Mon, 27 Apr 2015 12:18:16 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: getopt_long incompatibility
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
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.
