Skip to content

Fix issue 16432 - JSON incorrectly parses to string#5005

Closed
wilzbach wants to merge 2 commits intodlang:masterfrom
wilzbach:fix-16432
Closed

Fix issue 16432 - JSON incorrectly parses to string#5005
wilzbach wants to merge 2 commits intodlang:masterfrom
wilzbach:fix-16432

Conversation

@wilzbach
Copy link
Contributor

@wilzbach wilzbach commented Dec 30, 2016

The entire json module seems to require a bit of love - though I am still hoping for std.data.json

@dlang-bot
Copy link
Contributor

Fix Bugzilla Description
16432 JSON incorrectly parses to string

@wilzbach
Copy link
Contributor Author

wilzbach commented Jan 4, 2017

Great it seems that the floating point behavior on Win32_64 is different to all other machines and architectures (yep - even Win32). This could be due to a different C runtime which provides snprintf which is used by formattedWrite in std.format.
If someone has a 64-bit Windows machine, it would be great to know what the following yields:

import std.format, std.stdio;
format("%.18g", 1e18 - 65).writeln;
format("%.18g", 1e18 - 64).writeln;

@WebDrake
Copy link
Contributor

@wilzbach why not just add in a temporary patch which does the writelns in the unittests, then check the auto-tester's console output? Or include the formatted string in the assert error message?

@ghost
Copy link

ghost commented Jan 1, 2019

This is why Grisu or RYU would be needed. These small differences due to different standard C library printf would be fixed for good.

@berni44
Copy link
Contributor

berni44 commented Mar 18, 2021

Great it seems that the floating point behavior on Win32_64 is different to all other machines and architectures (yep - even Win32). This could be due to a different C runtime which provides snprintf which is used by formattedWrite in std.format.
If someone has a 64-bit Windows machine, it would be great to know what the following yields:

import std.format, std.stdio;
format("%.18g", 1e18 - 65).writeln;
format("%.18g", 1e18 - 64).writeln;

Meanwhile snprintf is removed for %g (at least for double and float). Unfortunately this is exactly the gap between %e-like and %f-like output, which may still differ between different computers. The reason for this is the way D handles floating point math (internal promotion to real) and the fact, that floating point math might differ slightly, depending on the way the calculations are optimized by the compiler. To avoid this, a software floating point unit with predictable results would be needed, IMHO an overkill. See #7836 for more on this.

@RazvanN7
Copy link
Collaborator

Closing in favor of the newer PR.

@RazvanN7 RazvanN7 closed this Mar 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants