Round-trip format specifier incorrect for some doubles on some x64 computers

[hickford]

Reproduced from https://stackoverflow.com/questions/24299692/why-is-a-round-trip-conversion-via-a-string-not-safe-for-a-double?rq=1

Recently I have had to serialize a double into text, and then get it back. The value seems to not be equivalent:

double d1 = 0.84551240822557006;
string s = d1.ToString("R");
double d2 = double.Parse(s);
bool s1 = d1 == d2;
// -> s1 is False

But according to MSDN: Standard Numeric Format Strings, the "R" option is supposed to guarantee round-trip safety.

The round-trip ("R") format specifier is used to ensure that a numeric value that is converted to a string will be parsed back into the same numeric value

Why did this happen?

[appel1]

According to https://connect.microsoft.com/VisualStudio/feedback/details/914964/double-round-trip-conversion-via-a-string-is-not-safe there are programs that rely on this behavior and the documentation has been updated with a workaround that you should implement R yourself for x64. Unfortunately that workaround does not work in practice since there are many places like XmlConvert where it is not possible to override how doubles are formatted.

[tannergooding]

Now that dotnet/coreclr#22040 is merged, for .NET Core 3.0, ToString(), ToString("G"), ToString("R"), double.ToString("G17"), and float.ToString("G9") should now always produce a string that will roundtrip to the original value..

I will keep this open until an explicit testcase for 0.84551240822557006 can be added to CoreFX.