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

[Nico Weber]

On Thu, Jun 5, 2014 at 4:16 PM, Marshall Clow <mclow.lists at gmail.com> wrote:

>
> On Jun 4, 2014, at 5:49 PM, Nico Weber <thakis at chromium.org> wrote:
>
> On Thu, Jun 5, 2014 at 2:21 AM, Richard Smith <richard at metafoo.co.uk>
> wrote:
>
>> On Wed, Jun 4, 2014 at 3:27 PM, Joerg Sonnenberger <
>> joerg at britannica.bec.de> wrote:
>>
>>> On Wed, Jun 04, 2014 at 02:51:49AM +0200, Nico Weber wrote:
>>> > 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 looks like a bug in the standard.
>>>
>>
>> It is:
>>
>> http://lwg.github.io/issues/lwg-active.html#2009
>>
>
> Cool, thanks. I hope that proposed resolution gets a slightly more
> detailed text. Similar wording in the C standard apparently implies
> something along the lines of "`1.e60` is a valid IEEE 754 spelling of
> INFINITY, and INFINITY is a representable value" (
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_025.html ) (which as
> far as I understand is the interpretation that e.g. musl is using, so their
> strtof doesn't set ERANGE on this input.)
>
>
> Nico —
>
> Since this is an active LWG bug, I’d like to hold off on your patch until
> after the next committee meeting (which is the week after next).
>
> So it doesn’t get lost, can you open a bug, and attach the patch there.
> (You can assign the bug to me)
>

Filed PR19954, thanks :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140605/a672028e/attachment.html>