[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20141121184955.GA2284@euler>
Date: Fri, 21 Nov 2014 19:49:55 +0100
From: Felix Janda <felix.janda@...teo.de>
To: musl@...ts.openwall.com
Subject: Re: More GNU semantics for getopt_long?
Rich Felker wrote:
> > > > I also noticed that 66fcde4ae4a52ae3edb1cf237ce2c22d08d7a062 seems
> > > > to have broken getopt_long: Even if optstring does not begin with
> > > > ':', getopt_long will return ':' if a long option is not supplied
> > > > by its required argument.
> > >
> > > Is this still broken, and if so, could you provide a short testcase I
> > > could use for checking it and figuring out what's wrong?
> >
> > Nothing has changed. Below is a testcase.
> >
> > --Felix
> >
> > #include <stdio.h>
> > #include <getopt.h>
> >
> > int main(void) {
> > struct option opts[2] = {{"opt", 1, NULL, 'o'}, {0, 0, 0, 0}};
> > int ret;
> >
> > ret = getopt_long(2, (char *[3]){"a", "--opt", 0}, "", opts, NULL);
> > if (ret != '?') printf("'%d' != '%d'\n", ret, '?');
> >
> > return 0;
> > }
>
> Are you sure it's related to the change in that commit? I think it was
> always this way. getopt_long.c seems to return ':' unconditionally
> when the argument is missing rather than returning '?'.
Right, it doesn't seem to be related to the commit.
> We probably
> also need to look into what the appropriate behavior should be for how
> the parsing state is left when errors like this are encountered,
> although I would guess optind should just end up pointing to the null
> pointer at the end of argv so that subsequent calls report that
> they're at the end.
The POSIX page on getopt confuses me a bit. It says:
The getopt() function shall return the next option character (if one
is found) from argv that matches a character in optstring, if there
is one that matches. If the option takes an argument, getopt() shall
set the variable optarg to point to the option-argument as follows:
1. If the option was the last character in the string pointed to by
an element of argv, then optarg shall contain the next element of
argv, and optind shall be incremented by 2. If the resulting
value of optind is greater than argc, this indicates a missing
option-argument, and getopt() shall return an error indication.
So should optind be increased by 2 to point into nirvana when the
argument is missing? Considering the Example below on the page, I think
that it rather should behave as you have described.
Felix
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.
