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

Not expected implicit cast of 000 to 0 #1404

Open
benoit-intrw opened this issue May 4, 2017 · 6 comments
Open

Not expected implicit cast of 000 to 0 #1404

benoit-intrw opened this issue May 4, 2017 · 6 comments
Labels

Comments

@benoit-intrw
Copy link

I didn't expect the following behavior:

$ echo '{"dummy": 000}' | jq .
{
  "abc": 0
}

I expect jq behave for example like this:

$ echo '{"abc": 000}' | python -m json.tool
Expecting , delimiter: line 1 column 10 (char 9)

I didn't know that jq cannot be used to validate JSON.

@nicowilliams
Copy link
Contributor

Thanks. This can't really be seen as a jq-specific JSON extension. It has to be fixed.

@nicowilliams nicowilliams added this to the 1.7 release milestone Dec 11, 2017
@onlined
Copy link

onlined commented Nov 14, 2018

Can I take this? I think checking literal before sending to jvp_strtod.

@leonid-s-usov
Copy link
Contributor

It is covered in the FAQ

𝑸: Can jq be used as a JSON validator?

A: Strictly speaking, no. Although jq is fairly strict about what it accepts as JSON, there is currently no "strict" mode, and jq will quietly accept some not-strictly-valid JSON texts, e.g. 00 is mapped to 0. See also the subsection on numbers below. However jq can be very helpful in pinpointing discrepancies from JSON.

I was, too, under impression that this incompatible behaviour should be fixed. But over time I got to thinking that it does make sense to use dedicated tools if one wants to validate JSON.
Maybe it could be an option to specify on the command line whether to be strict or not, but the default behaviour shouldn't change

At the end, let me just mention that this specific limitation of JSON doesn't make too much sense as well, as it come out of a specific ECMAScript syntax where leading zero was denoting an octal literal. This is not used anywhere else and also deprecated in java script.

This answer covers the topic, the comments as also helpful https://stackoverflow.com/a/27361596/5171225

@onlined
Copy link

onlined commented Nov 14, 2018

According to what you said, it is unnecessary to fix this behavior. But what is bad about fixing this?

@leonid-s-usov
Copy link
Contributor

technically, it shouldn't be fixed, since it's a documented feature. Changing this behaviour will break backward compatibility.

However adding a program switch to enable --strict mode would be fine in my opinion.
I don't see anything bad if you committed a PR doing just that.

Still, the final decision here is on the maintainer's shoulders.

@mirabilos
Copy link

Similarily:

$ echo '[.1,0.2]' | jq -c .
[0.1,0.2]

This is more than just unexpected, not documented in the manual page, and in the absence of a strict option makes jq catastrophically violate the JSON spec. JSON can only function if everyone adheres to the spec.

Forwarded from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878091

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

No branches or pull requests

6 participants