getsubopt behavior

getsubopt behavior

[Rich Felker]

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

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?

Rich

Re: getsubopt behavior

[Natanael Copa]

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