[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Jul 2011 13:44:57 +0200
From: Luka Marčetić <paxcoder@...il.com>
To: musl@...ts.openwall.com
Subject: Re: cluts - numeric test expectations
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
Content of type "text/html" skipped
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.
