[Backport release-25.05] lib: fix overflowing fromHexString tests and example#434217
Merged
emilazy merged 2 commits intorelease-25.05from Aug 16, 2025
Merged
[Backport release-25.05] lib: fix overflowing fromHexString tests and example#434217emilazy merged 2 commits intorelease-25.05from
fromHexString tests and example#434217emilazy merged 2 commits intorelease-25.05from
Conversation
This was cherry‐picked from <#266705> and merged as part of <#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 6673e05)
`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 449ad44)
13 tasks
nixpkgs-ci
bot
added
10.rebuild-linux: 1-10
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bot-based backport to
release-25.05, triggered by a label in #433710.