Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 16 Dec 2016 13:15:01 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: getsubopt behavior

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

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.