Re: More GNU semantics for getopt_long?

[Rich Felker <dalias@libc.org>]

On Wed, Nov 19, 2014 at 07:44:50PM +0100, Felix Janda wrote:
> Rich Felker wrote:
> > I'd like to resume working on getting this integrated, especially
> > since one of the main Roadmap goals for 1.1.6 is solving the remaining
> > issues Alpine Linux is matching musl for, of which getopt_long is one.
> 
> Thanks for coming back to this.
> 
> > > 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 '?'. 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.

Rich