c++ - Discrepancy between istream's operator>> (double& val) between libc++ and libstdc++

Question

With my recent upgrade to Mac OS X 10.9 the default standard C++ library changed from libstdc++ to libc++. Since then I observe unexpected behaviour of the stringstream operator>>(double) documented in the code example below.

In summary the libc++ seems to have problems with extracting double values from stringstreams when the double value is followed by a letter.

I already checked the standard (2003) but I can't find any specific information if extraction should work in this case or not.

So I would be grateful for any input whether this is a bug in libc++ or libstdc++.

#include <sstream>
#include <iostream>

using namespace std;

void extract_double(const string & s)
{
  stringstream ss;
  double d;

  ss << s;
  ss >> d;
  if(!ss.fail())
    cout << "'" << ss.str() << "' converted to " << d << endl;
  else
    cout << "'" << ss.str() << "' failed to convert to double" << endl;
}

int main()
{
  extract_double("-4.9");
  extract_double("-4.9 X");
  extract_double("-4.9_");
  extract_double("-4.9d");
  extract_double("-4.9X");
}

Compiling the code with c++ --stdlib=libc++ streamtest.cxx gives

'-4.9' converted to -4.9
'-4.9 X' converted to -4.9
'-4.9_' converted to -4.9
'-4.9d' failed to convert to double
'-4.9X' failed to convert to double

Compiling the code with c++ --stdlib=libstdc++ streamtest.cxx gives

'-4.9' converted to -4.9
'-4.9 X' converted to -4.9
'-4.9_' converted to -4.9
'-4.9d' converted to -4.9
'-4.9X' converted to -4.9

Compiler version is

$ c++ --version
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

Answer 1

It looks like that libstdc++ is right and libc++ is wrong, according to the 22.4.2.1.2 of the (2011) standard.

At stage 2,

If it [the character - n.m.] is not discarded, then a check is made to determine if c is allowed as the next character of an input field of the conversion specifier returned by Stage 1 ["%g" in this case - n.m.] . If so, it is accumulated.

Since %g conversion specifier does not admit d or X characters, the character is not accumulated. It is not discarded either (only group separator characters can be discarded). Therefore Stage 2 must end at this point.

Then at stage 3 accumulated characters are converted.

It looks like libc++ erroneously accumulates d and X at stage 2, then attempts to convert them, and this fails.