Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 1 Jun 2017 11:23:25 +0200
From: Natanael Copa <>
To: Rich Felker <>
Subject: Re: getsubopt behavior


Sorry for late reply.

On Fri, 16 Dec 2016 13:15:01 -0500
Rich Felker <> wrote:

> POSIX leaves a lot about getsubopt under-specified:
> 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):
>     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:

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:
> 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:
> 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?


> 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.