ostream writes a double that istream can't read

[llvmbot]

Bugzilla Link	39012
Version	unspecified
OS	All
Reporter	LLVM Bugzilla Contributor
CC	@ecnelises,@mclow,@N-Dekker,@pazner

Extended Description

It appears libc++ incorrectly sets input stream failbit when reading subnormal floating point numbers. Here's an example:

#include <iostream>
#include <string>
#include <sstream>

int main()
{
    constexpr double x {1e-320};
    std::ostringstream oss {};
    oss << x;
    const auto str_x = oss.str();
    std::istringstream iss {str_x};
    double y;
    if (iss >> y) {
        std::cout << y << std::endl;
    } else {
        std::cout << "Nope" << std::endl;
    }
}

Compiling with Clang/libc++, results in "Nope" being printed, while with GCC/libstdc++, the value of the double is printed - as I would expect.

I also reported this behaviour in StackOverflow: https://stackoverflow.com/questions/52410931/why-does-clang-stdostream-write-a-double-that-stdistream-cant-read.

[llvmbot]

I have tried the example shared by you and able to get the same output for both cases.

Case 1: clang++/libc++
Case 2: gcc/libstdc++

the output in both the cases is "9.99989e-321"

Do you still see the problem from your side.
May know the specifications and clang version which you tried ?

My system's Specifications:
Clang version - 3.8.0
OS - Ubuntu 16.04.6 LTS

Thanks

[pazner]

I also observe this same behavior with clang++ 10.0.1 and 11.0.0 on Mac and Linux when using libc++. The example code outputs "Nope" instead of "9.99989e-321".

Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0

and

clang version 10.0.1
Target: x86_64-unknown-linux-gnu

[N-Dekker]

Thanks for reporting this issue, Daniel!

Just to let you know, I just encountered the very same problem, when trying a round trip of std::numeric_limits::denorm_min(). Also in my case, iss.fail() returned true after the round trip, which seems incorrect and inconvenient.

I tried AppleClang 12.0.0.12000032 on macos-10.15 (10.15.7), running on a GitHub Actions VM.

Hope it isn't so hard to fix!

[phillip-keldenich]

I can reproduce this bug (or a very similar one) on both MacOS and Linux with the following versions:

test program:

#include <sstream>
#include <iomanip>
#include <iostream>

int main() {
  std::stringstream input("4.940656458412465442e-324");
  char *end;
  double stod = std::strtod("4.940656458412465442e-324", &end);
  std::cout << stod << std::endl;
  double x = 100.0;
  if(input >> x) {
    std::cout << "READING TO DOUBLE WORKED! RESULT: " << std::setprecision(19) << x << std::endl;
  } else {
    std::cout << "READING TO DOUBLE FAILED!" << std::endl;
  }
}

Notably, std::strtod does NOT produce an error, it reads the double value correctly, and end points at an empty C string afterwards.

MacOS:

clang++ --version
Apple clang version 15.0.0 (clang-1500.3.9.4)
Target: x86_64-apple-darwin23.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Linux (Ubuntu 22.04):

clang++ --version
Ubuntu clang version 14.0.0-1ubuntu1.1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

libstdc++ on linux works fine (both when compiling with g++ and with clang++ without -stdlib=libc++) and reads the number correctly.

[quantumsteve]

What is the current status of this issue? I found what looks like the same issue in clang 19.1.0. The second number 5 is read correctly if I remove -stdlib=libc++, change std::vector<float> to std::vector<double> or add infile.clear() after reading the first value.

#include <iostream>
#include <sstream>
#include <vector>

int main(int, char**){

    std::istringstream infile("-2.34001e-40\n5");

    std::vector<float> x(2);

    infile >> x[0];
    infile >> x[1];

    std::cout << x[0] << '\n';
    std::cout << x[1] << '\n';

    return 0;
}

https://godbolt.org/z/sjjed7ssq

[Fedr]

Another test case:

#include <sstream>
#include <iostream>

int main() {
    std::istringstream s( "1.4013e-45" );
    float f;
    s >> f;
    std::cout << s.fail() << ": " << f;
}

All implementations parse f=1.4013e-45 without rounding errors. But only libc++ sets fail-bit of the stream. Online demo: https://gcc.godbolt.org/z/8fs8fvh7P