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