FloatToJSON

[David Robb 0]

Hello Delphi-Praxis!

 

I discovered a change to System.JSON as compared to Rio/Sydney:

 

function FloatToJson(const Value: Extended): string;
var
  Buffer: array[0..63] of Char;
  L: Integer;
begin
  L := FloatToText(Buffer, Value, fvExtended, ffGeneral, 17, 0, JSONFormatSettings);
  Buffer[L] := #0;
  if (StrScan(Buffer, '.') = nil) and (StrScan(Buffer, 'E') = nil) and
     not (Value.SpecialType in [fsInf, fsNInf, fsNaN]) then
  begin
    Buffer[L] := '.';
    Buffer[L + 1] := '0';
    Inc(L, 2);
  end;
  SetString(Result, Buffer, L);
end;

 

We are appending ".0" to all extended values if FloatToText doesn't do that.  This causes Currency values to be formatted as e.g. "3.0" instead of "3".

 

Should I report this to QC?

 

[Der schöne Günther 316]

Stuff like that makes me lose all hope. They still don't appear to have at least a minimal test coverage for the standard library.

 

It was already reported and is allegedly fixed in "RAD Studio 12 Athens Patch 1"

See: [RSP-43463] JSON serialization error with scientific double notation - Embarcadero Technologies

 

--

Also, I have absolutely no clue why they decided to add this in the first place. The JSON specifications are crystal clear:

https://ecma-international.org/publications-and-standards/standards/ecma-404/

Quote

JSON is agnostic about the semantics of numbers. (...) A number is a sequence of decimal digits with no superfluous leading zero. It may have a preceding minus sign (U+002D). It may have a fractional part prefixed by a decimal point (U+002E) (...)

 

See also:

RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format (ietf.org)

 

Edited March 15 by Der schöne Günther

[DelphiUdIT 176]

I don't understand what is bad here.

 

"FloattoJson" means transform a float value in Json reppesentation ... and this means that should be ".x" in the case that there are not "." or "E" symbol.

 

This is true and not questionable, but the real meaning to know if that Json format is a "standard" float or a currency is in this phrase:

 

Quote

JSON instead offers only the representation of numbers that humans use: a sequence of digits. All programming languages know how to make sense of digit
sequences even if they disagree on internal representations. That is enough to allow interchange.

 

So, I can write this values:

 

(1)          <- May be a integer, but you can read it like "base 10", binary, hex, octal ....

(1E0)      <- May be a integer, but also a float (and I saw the scientific notation generally is taken like a float) and yes it's "base 10"

(1.0)       <- It's a float "base 10" or currency  ?

(1.00)     <- It's float "base 10" or currency ?

 

But all this representations are subjective to Json ....

Edited March 15 by DelphiUdIT

[Uwe Raabe 2057]

1 hour ago, Der schöne Günther said:

I have absolutely no clue why they decided to add this in the first place.

Probably because of this one: https://quality.embarcadero.com/browse/RSP-38387

[David Robb 0]

Thank you everybody for the replies.  Believe it or not I couldn't remember where the current iteration of the quality portal was since my computer died :).  Bookmarked!

 

I don't think this is a serious issue; maybe it's not an issue at all.  If we follow the robustness principle we'll be liberal in what we accept and conservative in what we emit.  And if your JSON parser can't handle a ".0" in a currency/float value you've got some big problems.

 

Marco's comment in issue [RSP-36188] Adding isDouble() function in TJSONNumber - Embarcadero Technologies is interesting:

 

Sync status from internal system, internal issue closed on Feb 16, 2023 by Marco Cantù with comment:
JavaScript and .NET/JSON implementation don't force add ".0" part for floating-point data. Only Python goes in that direction...

 

 

[DelphiUdIT 176]

58 minutes ago, David Robb said:

JavaScript and .NET/JSON implementation don't force add ".0" part for floating-point data. Only Python goes in that direction...

But is not forbidden:

 

6 hours ago, Der schöne Günther said:

.... It may have a fractional part prefixed by a decimal point (U+002E) (...)

 

[Der schöne Günther 316]

My point is that it was not necessary to add this in the first place.

 

Without knowing better, they got talked into changing a working part of the RTL, adding new bugs and breaking existing code.