[llvm-bugs] [Bug 36914] New: libc++ incorrectly treats operator>>(istream& unsigned int&) as an error when converting negative values
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Mar 26 19:48:28 PDT 2018
https://bugs.llvm.org/show_bug.cgi?id=36914
Bug ID: 36914
Summary: libc++ incorrectly treats operator>>(istream& unsigned
int&) as an error when converting negative values
Product: libc++
Version: 6.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangbugs at nondot.org
Reporter: billy.oneal at gmail.com
CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com
Consider the following program:
#include <iostream>
#include <sstream>
int main()
{
std::istringstream a("-1");
unsigned i;
a >> i;
if (a.fail())
std::cout << "Bug\n";
else
std::cout << "Ok\n";
std::istringstream b("4294967296");
b >> i;
if (b.fail())
std::cout << "Ok\n";
else
std::cout << "Bug\n";
return 0;
}
libc++ thinks that -1 isn't representable in the type unsigned int, and so
treats this as an error. However, the standard disagrees with this. N4727
[istream.formatted.arithmetic] says that the operator>> calls locale's num_get.
[facet.num.get.virtuals]/3 says it reads as if by scanf %u. C11 7.21.6.2/12
says that %u behaves as if by strtoul. C11 7.22.1.4/5 says:
If the subject sequence begins with a minus sign, the value resulting from
the conversion is negated (in the return type).
That means that the parsing should remember that there was a minus sign, parse
the number as an unsigned int (with usual ERANGE checks), then, because the
input started with a minus sign, negate the resulting value.
(I ran into this bug when a user reported that they expected MSVC++ to treat -1
input as an error here; but libstdc++ agrees with us in not setting failbit
here, and C's rules, however bizarre, do not support setting failbit here)
--
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/20180327/21accaca/attachment.html>
More information about the llvm-bugs
mailing list