Floating-point NaN or Infinity values should be allowed as a feature

[Dani-Hub]

The JSON specification doesn't support special floating values such as any NaN value or +/-infinity. But many (if not most) Json libraries at least provide a special Flag to allow them. As an example see the flag serializeSpecialFloatingPointValues of the google-Gson library:

http://google-gson.googlecode.com/svn-history/trunk/gson/docs/javadocs/com/google/gson/GsonBuilder.html#serializeSpecialFloatingPointValues%28%29

It seems that the choice of representation chosen here (NaN for a NaN, Infinity and -Infinity for positive/negative infinity is quite popular and I recommend to use them when this feature is active.

Other JSON library with similar support:

https://github.com/aseemk/json5
https://simplejson.readthedocs.org/en/latest/

[cdunn2001]

Good idea. Would you like to implement this?

[Dani-Hub]

Sure, I will work on that.

[Dani-Hub]

While trying to start working, I'm wondering how to initialize a Writer object with Features. This support is needed to control the JSON output for infinities and NaNs.

According to the general documentation:

"This configuration object can be used to force the Reader or Writer to behave in a standard conforming way."

But only Reader objects can be constructed from a Features object.

What am I missing?

[cdunn2001]

Use neither Writer nor Features. Those are deprecated. (But if I add your macro, the compiler will get very noisy for our unit-tests.) Use StreamWriterBuilder. See the Advanced Usage section of the docs.

[Dani-Hub]

I would like to get some feedback regarding the design choices: The current trunk cannot handle NaN nor infinity for Visual Studio (presumably because of an implementation defect, because the gcc code writes +/-1e+9999 for infinities and null for NaN, but reads +/-infinity and 0, respectively) and a strict reading of the JSON spec means that these values are not valid. My suggestion would be that activating a special feature flag (such as "allowSpecialFloatingPointValues") will have the effect to output NaN, Infinity, -Infinity for these three value categories and will read them back to a floating point NaN or corresponding infinity values. But what should the behaviour be, if this flag is not set? Some libraries do not accept them while writing, some do not accept them while reading or writing and in such cases an exception is thrown. Or should this flag effectively allow three states: (a) The current behaviour (default), (b) exact mapping (as described above), or (c) hard error? I would like to collect some feedback to make acceptance of the intended feature more likely.

[cdunn2001]

We're changing 1e9999 to Infinity and null to NaN (for floats) only when the user has requested that feature. We will have a symmetrical feature in the Reader. We will not alter the current behavior when not set. And strict mode should follow the JSON spec.

For the feature's name, how about useSpecialFloats? It's a bit shorter.

Collecting feedback is a good idea! I hope you get some.

[Dani-Hub]

I completely agree with the first sentence, but I don't understand how to interpret "And strict mode should follow the JSON spec", because according to

http://www.ietf.org/rfc/rfc4627.txt

"Numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted."

My question was: How should that "not permitted" be implemented? This was the reason of my question related to exceptions.

[cdunn2001]

Strict mode will not include this new feature. In strict mode, the reader will reject any invalid symbol. Probably, it doesn't have to change at all.

• http://open-source-parsers.github.io/jsoncpp-docs/doxygen/class_json_1_1_char_reader_builder.html#a9c19e3c5475f9072d527810d4bf56749

As for how to reject, the reader returns false if it has a problem, and it shows the line of rejected input in the err string.

[Dani-Hub]

I'm still trying to figure out the architecture of the jsoncpp library to find the optimal way to implement this feature. I'm now stumbling across the valueToString functions, which seem to be public API, at least they can be referred to by the documentation:

http://open-source-parsers.github.io/jsoncpp-docs/doxygen/writer_8h.html

Given that these free function determine in a fixed way how primitive types (such as double) are converted into string forms, I don't understand how I could realize a different form of

std::string valueToString(double value);

that would produce the alternative output requested by this issue. I need some help to understand the choices that I would have for realizing an alternative double output (depending on a corresponding useSpecialFloats flag). Would it be feasible to provide a new function parameter with a default value such as:

std::string valueToString(double value, bool useSpecialFloats = false);

Why are these functions part of the public API anyway? Shouldn't they actually be moved to internal headers such as to header "json_tool.h"?

[cdunn2001]

valueToString() is public but should not be. (And we cannot remove it now.) It's ok to use a new internal-only alternative instead.

I'll be awk for a couple weeks, so take your time with your new ideas...

[Dani-Hub]

I'm following now all calls of valueToString(double) to potentially adapt them to invoke the correct output strategy (depending on the 'useSpecialFloats' flag) where appropriate (that is, excluding deprecated classes). This works quite well in StreamWriterBuilder where we have a settings_ member available, but it is completely unclear to me, how to read this setting flag within Json::Value, e.g. Value::asString(). Could you give me a hint, please? Thanks.

[cdunn2001]

Anyone calling Json::Value::asString() will be using a default writer. There is no way around that. (Not only would we have to modify Json::Value, which would break binary-compatibility, but we also would probably have to increase its size, which is a measurable penalty.)

That's fine. Just make it work for StreamWriterBuilder.