[llvm-bugs] [Bug 28704] New: num_get::do_get incorrect digit grouping check

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=28704

            Bug ID: 28704
           Summary: num_get::do_get incorrect digit grouping check
           Product: libc++
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: llvm-bugs at daryl.haresign.com
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com
    Classification: Unclassified

For a locale which specifies digit grouping, num_get::do_get will enforce
that the number read in contains the grouping character at the correct
locations.  It does this even if the number read in didn't have any grouping
characters present.

This is shown best with a code example:

  #include <iostream>
  #include <sstream>

  int main()
  {
    std::locale::global(std::locale("en_US.UTF-8"));
    std::istringstream iss("1024");
    int a = 0;
    iss >> a;
    std::cout << a << ", " << iss.fail() << std::endl;
  }

With libc++ this prints:

  1024, 1

With libstdc++ this prints:

  1024, 0

http://coliru.stacked-crooked.com/a/9283df64c2bd5142

The standard says:

> Digit grouping is checked. That is, the positions of discarded separators is
> examined for consistency with
> use_facet<numpunct<charT> >(loc).grouping(). If they are not consistent then
> ios_base::failbit is assigned to err.

http://eel.is/c++draft/facet.num.get.virtuals#4

Whilst the standard could be clearer, it seems one can take it to mean that as
there are no discarded characters, there is nothing to examine for consistency.

This is the approach that libstdc++ takes, as well as boost's lexical_cast:

https://svn.boost.org/trac/boost/ticket/5585

I think it's reasonable that libc++ changes its implementation to match.

-- 
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/20160725/db679f90/attachment.html>