Passing JsonSpecialFloats.yes to parseJSON prompts the parser to interpret
"NaN", "Infinite", and "-Infinite" as the special floating-point values they
represent.
Adds the overload parseJSON(JSONValue, SpecialFloats) that takes a JSONValue and
the JsonSpecialFloats flag so users do not have to pass maxDepth in order to
specify special float handling behavior.
Adds the SpecialFloats flag to JSONValue.toString, JSONValue.toPrettyString,
and JSONValue.toJSON.
Given SpecialFloats.yes, the special float values NaN, Infinity, and -Infinity
will be encoded as the strings "NaN", "Infinite", "-Infinite".
Given SpecialFloats.no, attempting to stringify a JSONValue containing a
special float value will throw.
This overrides the previous behavior of encoding special float values as
non-string literals, which resulted in non-standard JSON strings.
JSONValue.toString will output 'nan', 'inf', or '-inf', when it has type
JSON_TYPE.FLOAT and value double.nan/double.infinity/-double.infinity.
However, parseJSON would fail on encountering these values in a string.
This patch enables parseJSON to read special float values.
Defining opEquals seems to be needed for correct comparison of the union
used for store.
(cherry picked from commit 8bb22a65ee9650d40f817c47e61819864342ee72)
As far as I am aware, the C standard doesn't make any
guarantees about what the leading digit in the hex formats
is, nor about the number of exponent digits displayed by
default.
We should look into replacing the functions with our own
implementations to provide consistent behavior independent
of the host C runtime library, and potentially also allowing
the functionality to be used from CTFE.
This allows JSON to be used as a temporary serialization format when debugging an application as it becomes human- and diff-readable.
Empty JSON object/array is formatted as "{}"/"[]".
