Re: getsubopt behavior

[Natanael Copa <ncopa@alpinelinux.org>]

Hi,

Sorry for late reply.

On Fri, 16 Dec 2016 13:15:01 -0500
Rich Felker <dalias@libc.org> wrote:

> POSIX leaves a lot about getsubopt under-specified:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/getsubopt.html
> 
> It's not clear what happens to any of the pointed-to objects in the
> case where no keys match, but it seems generally agreed upon that
> *optionp advances to the next option (or end of string) and that the
> separator ',' if any is nulled out.
> 
> What's explicitly not specified is what happens to *valuep when
> getsubopt returns -1 (no key match):
> 
>     "APPLICATION USAGE
> 
>     The value of *valuep when getsubopt() returns -1 is unspecified.
>     Historical implementations provide various incompatible extensions
>     to allow an application to access the suboption text that was not
>     found in the keylistp array."
> 
> Glibc updates *valuep to point to the original value of *optionp (the
> whole "unrecognized_key=value" component, with any final ',' nulled
> out). This is rather useless, since the caller can just save the old
> value of *optionp and use it when getsubopt returns -1, but I found
> some code in v4l2-ctl that depends on it:
> 
> https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-ctl/v4l2-ctl-common.cpp?id=fd7e1db71eabbb81ff20a2ab97948612ef061edf#n693

I bumped in to this, and as you mentioned in IRC, I think v4l2-ctl
needs to be patched. There is no reason they should use getsubopt for
their use.

> On the other hand, FreeBSD nulls the pointer at *valuep, any final
> ',', AND any '=' character in the unrecognized subopt string, so that
> the "unrecognized_key=value" component is not even easily recoverable:
> 
> https://github.com/freebsd/freebsd/blob/22c7ee83f61dc73c60942c528108e8b6220ed350/lib/libc/stdlib/getsubopt.c
> 
> Reportedly Solaris and other sysv-type implementations match the glibc
> behavior.
> 
> musl currently nulls the pointer at *valuep but doesn't clobber the
> '='.
> 
> Being that POSIX allows any of them (by leaving it unspecified) and
> that the BSD behavior is actively destructive and undesirable (and
> perhaps not even conforming in that it clobbers data it doesn't seem
> to be specified to clobber), my leaning is to adopt the glibc/sysv
> behavior.
> 
> Note that the Linux man page documents the glibc behavior without
> documenting as an extensions:
> 
>     "Otherwise, -1 is returned and *valuep is the entire name[=value]
>     string."
> 
> 
> Source: http://man7.org/linux/man-pages/man3/getsubopt.3.html
> 
> Thoughts?

I think that linux users will expect the behavior in linux man-page, so
it might make sense to follow that to avoid unexpected surprises.

I am kind of ok with the current behavior too, but then we probably
should send a patch for man-pages?

-nc

> 
> Rich