> Given that we can't depend on people to do simple things like handling escape sequences correctly, that seems pretty important. (Also, the 'jq' command is nice.)
jq stores all numbers as doubles, which means it can't handle 64 bit ints (or larger integer numeric types).
It's otherwise a great tool and I wouldn't point out a negative such as this, but you did explicitly mention that you know JSON won't be fed to a bad parser.
That is what almost all JSON parsers do; even the spec says that you shouldn't rely on more precision than a double:
This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
Good to know about the JSON spec. The only JSON parser I used before jq was the Python stdlib parser. Python JSON correctly handles big integers, which lead to my (out of spec) expectations for jq to do the right thing.
jq stores all numbers as doubles, which means it can't handle 64 bit ints (or larger integer numeric types).
It's otherwise a great tool and I wouldn't point out a negative such as this, but you did explicitly mention that you know JSON won't be fed to a bad parser.