json: Fix handling of NaN/Infinity #15192
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The JSON spec requires that these special values be serialized as null; the current serialization breaks any conformant JSON parser. So encoding needs to output "null", to_json on floating-point types can return Null as well as Number, and reading null when specifically expecting a number should be interpreted as NaN. There's no way to round-trip Infinity.
|
I believe that @erickt has been working on some refactorings of serialization, so he may be best to ask about the duplication. |
bors
added a commit
that referenced
this pull request
Jun 26, 2014
The JSON spec requires that these special values be serialized as "null"; the current serialization breaks any conformant JSON parser. So encoding needs to output "null", `to_json` on floating-point types can return `Null` as well as `Number` values, and reading a `Null` value when specifically expecting a number should be interpreted as NaN. There's no way to round-trip Infinity through JSON.
This is my first attempt at both writing Rust and opening pull requests, so please dial your derp detector up to eleven when reviewing. A `rustc --test lib.rs` in `libserialize` passes all tests; a `make check` of the whole tree fails with the error below, but it doesn't look obviously related and the docs say that `make check` is known to be flaky on Windows.
---- [compile-fail] compile-fail/svh-change-significant-cfg.rs stdout ----
task '[compile-fail] compile-fail/svh-change-significant-cfg.rs' failed at 'called `Result::
unwrap()` on an `Err` value: couldn't create file (end of file (unknown error); path=i686-pc-mingw32
\test\compile-fail\svh-a-base.err; mode=truncate; access=write)', C:\msys\home\Mike\rust\src\libcore
\result.rs:545
Incidentally, it may just be my lack of familiarity with the language and its idioms, but the duplication between `Encoder`/`PrettyEncoder` had a distinct code smell to it. The size of the file (~3500 lines) also made it a bit hard to navigate. Has there been any discussion of refactoring and/or breaking it up? I couldn't find anything in Issues except the ancient #9028.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The JSON spec requires that these special values be serialized as "null"; the current serialization breaks any conformant JSON parser. So encoding needs to output "null",
to_jsonon floating-point types can returnNullas well asNumbervalues, and reading aNullvalue when specifically expecting a number should be interpreted as NaN. There's no way to round-trip Infinity through JSON.This is my first attempt at both writing Rust and opening pull requests, so please dial your derp detector up to eleven when reviewing. A
rustc --test lib.rsinlibserializepasses all tests; amake checkof the whole tree fails with the error below, but it doesn't look obviously related and the docs say thatmake checkis known to be flaky on Windows.Incidentally, it may just be my lack of familiarity with the language and its idioms, but the duplication between
Encoder/PrettyEncoderhad a distinct code smell to it. The size of the file (~3500 lines) also made it a bit hard to navigate. Has there been any discussion of refactoring and/or breaking it up? I couldn't find anything in Issues except the ancient #9028.