From: "Luka Marčetić" <paxcoder@gmail.com>
To: musl@lists.openwall.com
Subject: Re: cluts - numeric test expectations
Date: Fri, 15 Jul 2011 13:44:57 +0200 [thread overview]
Message-ID: <4E202839.8030103@gmail.com> (raw)
In-Reply-To: <20110715033729.GP16618@brightrain.aerifal.cx>
[-- Attachment #1: Type: text/plain, Size: 3296 bytes --]
On 07/15/2011 05:37 AM, Rich Felker wrote:
> Tests which expect strto* on "0x[junk]" to fail rather than returning
> 0 with endptr pointing at the 'x': both my interpretation of the
> standard and glibc agree that this expectation is wrong, as does at
> least one expert I asked. I think these should be changed to accept
> the current musl and glibc behavior and treat anything else as a
> failure. (Note that the scanf tests, however, seem to be fine.)
For those who missed the chat: We talked about non-base-16 tests which
do expect endptr to end up pointing at 'x'. Rich's argument against this
behavior was "longest initial subsequence" (strlen of "0x">"0"), and
mine was "of the expected form" [see strtol SUSv4 page to see what I
mean]. We ended up agreeing on the latter. It follows that the above
objection of Rich's is to hexadecimal "0x*" tests.
Rich: Now that you pointed it out, I do believe that the standard
applies this logic to base-16 tests as well, because of this one line:
"If the value of/base /is 16, the characters 0x or 0X may optionally
precede the sequence of letters and digits". The key word here is
"optionally". I guess I missed this, expecting base 16 to take only "A
hexadecimal constant [which] consists of the prefix 0x or 0X followed by
a sequence of the decimal digits and letters". But the latter definition
(without optionality), refers to cases where base is 0, not 16. One
might think that base 0 should then match "0x", but I don't think so -
it brings us back to "expected from".
In short: I think, like Rich said, absolutely all "0x" tests should
point to 'x'. Any objections? Speak now or forever hold your peace*.
*where 'forever' is a definite (quite possibly short) amount of time ;-)
> Tests which expect *endptr==str after overflow (ERANGE): I believe
> this expectation is incorrect, but glibc seems to disagree. I can't
> find any language in the standard to support the behavior explicitly,
> or to allow it as an interpretation. The definition of "subject
> sequence" makes no reference to the value having to fit in a
> certain-size integer type,
Though I did remake ERANGE tests (see "> MAX" commit) with the
endptr-nptr offset strlen of nptr, I've now reviewed the case, and I
think it should still be endptr==nptr. There is no actual conversion in
my opinion: *_MAX returned value simply means out of scope. See "Return
value" section: "Upon successful completion, these functions shall
return the converted value". The reason I say it's not a converted value
is because successful completion it is not, see "Errors" section: "These
functions shall fail if: (...) [ERANGE] The value to be returned is not
representable.". Not that I can't see con arguments.
> only that it belong to a clearly-defined
> regular language, e.g. /[-+]?(0x)?[[:xdigit:]]+/ for base==16.
Is that your regexp or an official one (if there is such a thing)?
Because I think, in light of what you've said above regarding the first
issue, it might be wrong: Wouldn't this regexp greedily match "0x" for
you, instead of the shorter [[:xdigit:]], the latter of which is alone
of the "expected form"?
> Otherwise, all the integer tests look okay. I still need to review the
> floating point ones.
>
> Rich
I appreciate that.
-Luka
[-- Attachment #2: Type: text/html, Size: 7043 bytes --]
next prev parent reply other threads:[~2011-07-15 11:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-15 3:37 Rich Felker
2011-07-15 11:44 ` Luka Marčetić [this message]
2011-07-15 13:36 ` Rich Felker
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=4E202839.8030103@gmail.com \
--to=paxcoder@gmail.com \
--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).