[libc++ patch] (and/or standard bug?): Let std::stof() call strtod / wcstod instead of strtof / wcstof

[Nico Weber]

Hi,

21.5p4 and 21.5p11 say that std::stof() and std::stod() are both supposed
to call strtod() (for char*) or wcstod() (for wchar_t*). libc++ currently
calls strtof() / wcstof() from std::stof(), so the attached patch fixes
this.

This has a surprising effect: 21.5p6 and 21.5p13 say that stof() should
throw out_of_range if strtod / wcstod set errno to ERANGE. Now, for
stof("1.e60") will call strtod("1.e60", ...). 1.e60 fits in a double, so
strtod() won't set ERANGE. But stof() returns a float, and this double
converted to a float does result in INFINITY. So it sounds like the
standard demands that stof("1.e60") returns INFINITY but does not throw,
while std::stod("1.e360") is supposed to return INFINITY and
throw out_of_range (assuming the C library sets ERANGE in this case, which
seems like a reasonable assumption.)

So I'm not sure if the standard is specifying what it intends to specify
here. If someone familiar with DRs could report, that'd be cool.

Nevertheless, the attached patch makes libc++ do what the standard demands
(and updates one test).

Nico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140604/b63cf555/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libcxx-stof.patch
Type: application/octet-stream
Size: 1836 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140604/b63cf555/attachment.obj>