Emily
86303ffb05
JSON has only one numeric type, with vague semantics. [RFC 8259] says: > This specification allows implementations to set limits on the range > and precision of numbers accepted. Since software that implements > IEEE 754 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. > > 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. [RFC 8259]: <https://www.rfc-editor.org/rfc/rfc8259.html#section-6> Floating‐point numbers are annoying to deal with in Nix, so it optimistically parses integer‐looking literals as Nix‐language integers where possible. Nixpkgs relies on this behaviour, as it backs its `lib.toInt` family of functions with `builtins.fromJSON` in lieu of a real integer‐parsing built‐in, and treats floating‐point outputs as an error. Therefore, dealing with integer‐looking JSON number literals that are outside the interoperable range is unavoidable. However, this raises the question of how literals that look like integers, but exceed the range of a Nix‐language integer, should be handled. The JSON library we use attempts to represent integer‐looking literals as a unsigned or signed C++ integer type before falling back to floating‐point numbers. This means that we were parsing literals below −2⁶³ as floating‐point numbers, while rejecting ones above (2⁶³ + 1) with an error. This was done to avoid the C++ undefined behaviour in the previous code path, but is hard to justify. This change causes them to both be parsed as floating‐point numbers. The alternative would be to reject the signed case too. However, I believe that is less consistent with how JSON handles its single numeric type, less interoperable with JSON documents found in the wild, and that it is preferable to avoid the function being needlessly partial in this case. It does mean that round‐tripping is less lossless than before, but extreme floating‐point values already caused these kinds of issues, and from JSON’s point of view that’s exactly what these literals represent. Only numeric values outside the RFC’s suggested interoperable range will have any round‐tripping issues, and we continue to guarantee the behaviour on all values that can be represented as Nix‐language integers. Change-Id: I6a6a696412383e8a2cc160397716cb7f7bc7a2d4
Lix
Lix is an implementation of Nix, a powerful package management system for Linux and other Unix systems that makes package management reliable and reproducible.
Read more about us at https://lix.systems.
Installation
On Linux and macOS the easiest way to install Lix is to run the following shell command (as a user other than root):
$ curl -sSf -L https://install.lix.systems/lix | sh -s -- install
For systems that already have a Nix implementation installed, such as NixOS systems, read our install page
Building And Developing
See our Hacking guide in our manual for instruction on how to set up a development environment and build Lix from source.
Additional Resources
- The Lix reference manual:
- Our wiki
- Matrix - #space:lix.systems
License
Lix is released under LGPL-2.1-or-later.