Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

With feature "arbitrary_precision" exponent marker get converted to lowercase #785

Closed
ruifengx opened this issue Jul 17, 2021 · 1 comment · Fixed by #786
Closed

With feature "arbitrary_precision" exponent marker get converted to lowercase #785

ruifengx opened this issue Jul 17, 2021 · 1 comment · Fixed by #786

Comments

@ruifengx
Copy link
Contributor

Comment in Cargo.toml for feature arbitrary_precision states:

This feature makes JSON -> serde_json::Number -> JSON produce output identical to the input.

But in serde_json::de::scan_exponent, for the exponent marker (e or E), a lowercase e is inserted unconditionally to the internal representation. Therefore, for an input JSON 1.9E10 for example, a "JSON -> serde_json::Number -> JSON" roundtrip results in JSON 1.9e10, which is different from the input JSON.

Is this behaviour intended? If no other code rely on e being lowercase, I suggest we insert an e or E based on the input. Some specification requires some fields always treated as string, and in case they are presented as numbers in JSON, they should be converted to strings verbatim. arbitrary_precision is the only method I found for such circumstances, and I believe it should behave as described in Cargo.toml.

P.S. If you see the above-mentioned change appropriate, I can make a PR for this.

@ruifengx
Copy link
Contributor Author

ruifengx commented Jul 17, 2021

After further investigating the implementation, I found out the plus sign in 1.9E+10 is also dropped during parsing... (thus 1.9E+10 -> 1.9e10)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

1 participant