[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 1 Jun 2017 11:23:25 +0200
From: Natanael Copa <ncopa@...inelinux.org>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: getsubopt behavior
Hi,
Sorry for late reply.
On Fri, 16 Dec 2016 13:15:01 -0500
Rich Felker <dalias@...c.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
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.
