[LLVMbugs] [Bug 19954] New: Decide what to do with stof

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=19954

            Bug ID: 19954
           Summary: Decide what to do with stof
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

Created attachment 12611
  --> http://llvm.org/bugs/attachment.cgi?id=12611&action=edit
possible patch

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140602/106976.html

"""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.)"""

"""It is:

http://lwg.github.io/issues/lwg-active.html#2009
"""

""" 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.)"""


"""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)."""


The attached patch changes stof to call strtod() and updates the test.  If the
committee decides that this should be changed, the stof() implementation needs
to be changed to do whatever the committee decides, and the test needs to be
updated. (Note that some C libraries, such as musl, don't set ERANGE for
INFINNITY in strtof().)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140605/3325eed3/attachment.html>