Here's a test case for the problem I point out in c++std-lib-17897. It shows
that operator>>(int&) behaves differently (and, I claim, incorrectly) from
operator>>(long&) or any other extractor except the one for short (which is
affected for the same reason).
$ cat t.cpp && g++ t.cpp -static && ./a.out
#include <cassert>
#include <locale>
#include <sstream>
struct NumPunct: std::numpunct<char>
{
std::string do_grouping () const { return "\3"; }
char do_thousands_sep () const { return ';'; }
};
template <class T>
T extract (const char *s)
{
std::istringstream strm (s);
strm.imbue (std::locale (strm.getloc (), new NumPunct));
T x = T ();
strm >> x;
assert ((strm.failbit | strm.eofbit) == strm.rdstate ());
return x;
}
int main ()
{
assert (123L == extract<long>("1;2;3"));
assert (123 == extract<int>("1;2;3"));
}
Assertion failed: 123 == extract<int>("1;2;3"), file t.cpp, line 26
Abort (core dumped)
--
Summary: istream::operator>>(int&) broken
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30561
