Re: [musl] Possible problem with getopt_long_only()

[Rich Felker <dalias@libc.org>]

On Thu, May 14, 2020 at 10:24:46AM +0100, Cristian Morales Vega wrote:
> I have not looked at the details. But killall from psmisc fails to
> parse "killall -10 <cmd>" when using musl 1.1.24 (the one used by the
> latest OpenWrt release, according to
> https://git.musl-libc.org/cgit/musl/log/src/misc/getopt_long.c the
> file has not been changed since 2018-09-12 anyway).
> 
> In https://gitlab.com/psmisc/psmisc/-/blob/v23.3/src/killall.c#L989
> optind is "1" if "killall -10 <cmd>" was used, but 2 if "killall -9
> <cmd>". So whether the signal number is only one digit or more makes
> the optind change. So killall only works with <10 signals.

It looks like this is not covered by the spec for getopt, but the musl
behavior is almost surely the "right" behavior here; what psmisc is
expecting makes it impossible to skip over unknown option flags and
continue parsing other ones chained together in the same argv[] slot,
e.g. -abc where 'a' is unknown but 'b' and 'c' are supported.

Trying to use getopt to handle options that are not in the syntax
getopt is designed to handle is mostly misguided, but I think it could
be fixed by saving optind *before* calling getopt and using the saved
optind as the location to look for - followed by digits or capital
letters, rather than using optind-1 after getopt returns an error.

> Not sure it's the same issue, but in case it's different and was never
> reported to you you may be interested also on
> https://github.com/JuliaLang/julia/pull/31946.

That's a different issue, where musl is clearly doing what's required
by the spec and other implementations are buggy; I commented as such
on the tracker. Thanks for pointing it out!

Rich