4 ms·

jq can't handle big numbers, it silently mangles them, beware! Was bitten by this twice already..

kemayo 9y ago
That's per the spec[1], enjoyably: Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values. 2^53 is only 9007199254740990, so it's not too hard to exceed that, particularly in things like twitter status ids. The recommended use is to have big numbers as strings, since it's the only way to reliably pass them around. (Yes, this is kind of horrible.) [1]: https://tools.ietf.org/html/rfc7159#section-6 https://tools.ietf.org/html/rfc7159#section-6
- falcolas 9y ago
  I have to admit, I was not familiar with this limitation. Thanks for pointing it out. And I'd go from "kind of horrible" to just "horrible". Integral bit limits are an implementation detail that every language has a way to overcome - they shouldn't be built into an encoding spec.
  - kemayo 9y ago
    Again, not saying this is a good thing, but it's an understandable consequence of the standardization partially involving "let's document how the browsers existing JS implementations deal with running eval on a string". It's easier to write the standard so that existing implementations fit it, rather than requiring changes from everyone.
    - falcolas 9y ago
      I imagine it depends on your aims. If your aim is just to document existing behavior, that's one thing. But if your aim is to create a new, simple, data interchange format, documenting existing implementations is only going to limit its usefulness. It could have forced the current implementations fixed instead of setting the bar. As pointed out upstream, we're dealing with a lot of data these days, and such limitations will only cause JSON to become marginalized or complicated with implementation-dependent workarounds, like integers in strings.
      - vidarh 9y ago
        The point is that JSON started out as "data you can eval() in Javascript" pretty much. It gained the traction it did because it is literally a subset of javascript object notation so it was trivial to support.
        zdkl 9y ago
        By the way is this whence the "stringly typed" phrase originated or are there previous instances?

That's per the spec[1], enjoyably: Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values. 2^53 is only 9007199254740990, so it's not too hard to exceed that, particularly in things like twitter status ids. The recommended use is to have big numbers as strings, since it's the only way to reliably pass them around. (Yes, this is kind of horrible.) [1]: https://tools.ietf.org/html/rfc7159#section-6 https://tools.ietf.org/html/rfc7159#section-6

falcolas 9y ago
I have to admit, I was not familiar with this limitation. Thanks for pointing it out. And I'd go from "kind of horrible" to just "horrible". Integral bit limits are an implementation detail that every language has a way to overcome - they shouldn't be built into an encoding spec.
- kemayo 9y ago
  Again, not saying this is a good thing, but it's an understandable consequence of the standardization partially involving "let's document how the browsers existing JS implementations deal with running eval on a string". It's easier to write the standard so that existing implementations fit it, rather than requiring changes from everyone.
  - falcolas 9y ago
    I imagine it depends on your aims. If your aim is just to document existing behavior, that's one thing. But if your aim is to create a new, simple, data interchange format, documenting existing implementations is only going to limit its usefulness. It could have forced the current implementations fixed instead of setting the bar. As pointed out upstream, we're dealing with a lot of data these days, and such limitations will only cause JSON to become marginalized or complicated with implementation-dependent workarounds, like integers in strings.
    - vidarh 9y ago
      The point is that JSON started out as "data you can eval() in Javascript" pretty much. It gained the traction it did because it is literally a subset of javascript object notation so it was trivial to support.
      - zdkl 9y ago
        By the way is this whence the "stringly typed" phrase originated or are there previous instances?