mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: getsubopt behavior
Date: Fri, 16 Dec 2016 13:15:01 -0500	[thread overview]
Message-ID: <20161216181501.GA25534@brightrain.aerifal.cx> (raw)

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


             reply	other threads:[~2016-12-16 18:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-16 18:15 Rich Felker [this message]
2017-06-01  9:23 ` Natanael Copa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161216181501.GA25534@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).