`fromHexString` is backed by `builtins.fromTOML`. Per [the TOML
v1.0.0 specification]:
> Arbitrary 64-bit signed integers (from −2^63 to 2^63−1) should be
> accepted and handled losslessly. If an integer cannot be represented
> losslessly, an error must be thrown.
[the TOML v1.0.0 specification]: <https://toml.io/en/v1.0.0#integer>
The saturating behaviour of the toml11 version currently used
by Nix is not lossless, and is therefore a violation of the TOML
specification. We should not be relying on it. This blocks the update
of toml11, as it became stricter about reporting this condition.
This, yes, is arguably an evaluation compatibility break. However,
integer overflow was recently explicitly defined as an error by
both Nix and Lix, as opposed to the C++ undefined behaviour it was
previously implemented as:
* <https://nix.dev/manual/nix/stable/release-notes/rl-2.25>
* <https://docs.lix.systems/manual/lix/stable/release-notes/rl-2.91.html#fixes>
This included changing `builtins.fromJSON` to explicitly
reject overflowing integer literals. I believe that the case for
`builtins.fromTOML` is comparable, and that we are effectively testing
undefined behaviour in TOML and the Nix language here, in the same way
that we would have been if we had tests relying on overflowing integer
arithmetic. I am not aware of any use of this behaviour outside of
these tests; the reverted toml11 bump in Nix did not break the 23.11
evaluation regression test, for example.
C++ undefined behaviour is not involved here, as toml11 used the C++
formatted input functions that are specified to saturate on invalid
values. But it’s still a violation of the TOML specification caused
by insufficient error checking in the old version of the library,
and inconsistent with the handling of overflowing literals in the
rest of Nix.
Let’s fix this so that Nix implementations can correctly flag up
this error and we can unblock the toml11 update.
(cherry picked from commit 449ad44f16)
This was cherry‐picked from
<https://github.com/NixOS/nixpkgs/pull/266705> and merged as part of
<https://github.com/NixOS/nixpkgs/pull/318712>, despite there being
a blocking review on the former pointing out these kinds of issues.
This documents some of the dodgy behaviour. It also can’t handle
negative literals. It might be worth considering deprecating and
dropping this, by inlining it into `lib.network.ipv6.fromString`,
its only in‐tree user.
(cherry picked from commit 6673e05ad0)
lib.strings.escapeC produces single‐digit hexadecimal strings for
character values ≤ 15, which results in an ambiguity. If the following
character is a hex digit, it will be interpreted as being part of the
escape sequence.
systemd, which also relies on C‐style escape sequences, does not
decode single‐digit sequences at all, even if unambiguous.
Padding the hexadecimal string with "0" avoids this problem.
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
Previously if function in defs had set pattern in argument,
this information would be lost.
This keeps functionArgs in set pattern,
by using functor and `__functionArgs`
that is later used by `lib.functionArgs`.
Before this patch, code like this would break generate invalid XML:
lib.generators.toPlist {} "ab<cd"
That's obviously bad, since the call to toPlist often happens through
indirection, as is the case in e.g. the nix-darwin project. A user might
not realize that they have to escape the strings.
This patch adds the argument 'escape' to lib.generators.plist and emits
a warning if it is not set to true. In a future release, this behavior
should become the default.
I have also added a note for future maintainers, in case I forget to
actually remove the deprecated functionality in a future release.
These utilities will now leave the string undisturbed if it doesn't need to be quoted (because it doesn't have any special characters). This can help generate nicer-looking command lines.
This also transitively improves the output of `lib.toGNUCommandLine` which uses `escapeShellArg` internally
`strings.trim` returns a copy of the string with all leading and trailing
whitespace removed.
`strings.trimWith` does the same thing, but calling code can decide
whether to trim the start and/or end of the string.
Add lib.meta.getLicenseFromSpdxIdOr as a variant of
lib.meta.getLicenseFromSpdxId that explicitly state the default
(fallback) value if there's no license matching the given SPDX ID.
makeOverridable is very careful to ensure the arguments to the
overridden function are the same as the input function. As a result,
the arguments of hello.override are exactly the same as the original
arguments of the hello function that produced the derivation.
However, callPackagesWith calls makeOverridable with a lambda that
does not propagate the arguments. The override function for a package
instantiated with callPackagesWith will not have the original
arguments.
For example:
nix-repl> lib.functionArgs hello.override
{ callPackage = false; fetchurl = false; hello = false; lib = false; nixos = false; stdenv = false; testers = false; }
nix-repl> lib.functionArgs openssl.override
{ }
By copying the arguments onto the inner lambda before passing it to
makeOverridable, we can make callPackage and callPackages behave the
same.
nix-repl> lib.functionArgs openssl.override
{ buildPackages = false; coreutils = false; cryptodev = false; enableSSL2 = true; enableSSL3 = true; fetchurl = false; lib = false; perl = false; removeReferencesTo = false; static = true; stdenv = false; withCryptodev = true; withPerl = true; }
This allows for adding new, conditionally set, derivation attributes
to an existing derivation without changing any output paths in the
case where the condition is not met.
