Weird behavior in Visual C++ in reading stream to a double

Question

I am encountering a weird issue in visual studio 2022 (version 17.7.1). In the following program:

#include <iostream>
#include <sstream>
using namespace std;

int main()
{
    istringstream istr("1e-07 3");
    double xx = 0;
    int yy = 0;
    istr >> xx >> yy;
    cout << "xx = " << xx << endl;
    return 0;
}

The program will print differently based on runtime library and platform toolset:

Toolset v143, Multi-threaded Debug or Multi-threaded: 1e-06
Toolset V143, Multi-threaded Debug DLL or Multi-threaded DLL: 1e-07
Toolset v142, Multi-threaded Debug or Multi-threaded: 1e-07
Toolset V142, Multi-threaded Debug DLL or Multi-threaded DLL: 1e-07

Can someone confirm this? I would be amazed if this is an actual bug in the compiler.

Thanks.

Calamander

I'm getting 1e-06 in 17.8.0 Preview 1.0 too. Odd :-) – Alainealair

Thanks, Ted. This is really bad and can cause major issues in the real world, Microsoft. Imagine we read a file and then save the data back. – Calamander

clang16.0.6 on Windows "clang-cl /Od /Zi /MTd .\a.cpp" produced 1e-07. Same with /MDd switch – Yen

Please file a bug with Microsoft. – Pudendas

Yes, I just filed a bug report with Microsoft. Thanks. – Calamander

@user1998863, is there a link to your bug report? – Sessile

developercommunity.visualstudio.com/t/… – Calamander

Reported Microsoft STL issue: github.com/microsoft/STL/issues/3980 – Geyser

this bug is now fixed in VS 2022 17.9 Preview 1: developercommunity.visualstudio.com/t/… – Calamander

I can confirm that this bug is fixed in vs 17.8.1 – Calamander

Answer 1

The function _Parse_fp_with_locale in xlocnum is returning "010e-7" whereas using the Debug DLL runtime it returns the correct value "01e-7". Someone has already submitted a fix https://github.com/microsoft/STL/pull/3982. For now you can workaround the issue by not putting leading zeroes on your exponents.

If you're feeling really brave then commenting out the following block on line 1018 of xlocnum seems to fix the issue:

if (_Seendigit) {
    *_Ptr++ = '0'; // put one back
}

Visual studio 2022 17.9 will contain this fix

Flanch

Thanks. Could you please comment why DLL-runtimes do not contain the bug? Is it because they were built from an older version of Microsoft STL? – Geyser

@Geyser you'd have to ask Microsoft, I'm not sure they publish this details anywhere – Flanch