[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 Apr 2018 10:50:37 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: getopt_long_only bug
On Thu, Apr 26, 2018 at 12:46:31PM +0200, Szabolcs Nagy wrote:
> i got the following bug report:
>
> $ cat a.c
> #include <stdio.h>
> #include <getopt.h>
>
> int main()
> {
> struct option lo[] =
> {
> {"emit-relocs", no_argument, NULL, 'q'},
> {"qmagic", no_argument, NULL, 'Q'},
> { 0 }
> };
>
> int li = -1;
> char* a[] = { "", "-q", NULL };
> int c = getopt_long_only(2, a, "q", lo, &li);
>
> printf("c=%c/%i\n", c, c);
>
> return 0;
> }
> $ ./a.musl
> c=Q/81
> $ ./a.glibc
> c=q/113
OK, this is a weird corner case. Apparently when in longonly mode,
short options need to be counted in addition to long ones for
determining if a partial match is unique.
The attached patch should solve the problem. Any review/comments would
be helpful. It uses an ugly inline strstr of sorts, because to use
strstr we'd need to copy to a temp buffer, and we wouldn't even
benefit since the string being searched is so short (usually 1 byte,
at most 4). The only reason it's there at all is because we committed
to supporting multibyte option chars in getopt.c so getopt_long_only
needs to handle them consistently.
Rich
View attachment "glo.diff" of type "text/plain" (1220 bytes)
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.
