3 ms·
In this particular though, the spec explicitly talks about that [0] > Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE7
by theamk 5y ago
In this particular though, the spec explicitly talks about that [0]
> 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...
[0] https://datatracker.ietf.org/doc/html/rfc7159#section-6 https://datatracker.ietf.org/doc/html/rfc7159#section-6
Which means that if you are putting 64 bit integers into JSON and require every bit to be used, you are not actually creating a JSON which is compatible with all the consumers. For example, such JSON is not compatible with browser. Here is what my Firefox's JQ console says:
>> x = '{"id":675127116845989888,"id_str":"675127116845989888"}'
<- "{\"id\":675127116845989888,\"id_str\":\"675127116845989888\"}"
>> JSON.parse(x)
<- Object { id: 675127116845989900, id_str: "675127116845989888" }
I'd say that JQ acting the same way as browsers is pretty reasonable, no?
- ggm 5y agoYea. I think so. But, I think people who are stuck in 64 bits forget about 128 bit digit strings being common now. I am more wrong than right: if you can point to a written spec saying "be not astonished" then POLA doesn't apply. And you did.
- tom_mellior 5y agoSince jq does something completely different from a browser, it would be reasonable for it to try harder in some respects. A tool that is supposed to pass certain data through unchanged... Should not change that data. Even if we can expect that data to eventually be rounded by the eventual consumer at some later time.