In reply to @goldstein:tty5.dev
I took a look and I’m not sure what kind of help is wanted there
feel free to ping me if I can help with something though

In reply to @goldstein:tty5.dev
happy to chat on some messenger that is not matrix

enjoy

shion:~
❭ nix run nixpkgs/nixpkgs-25.05-darwin#lixPackageSets.lix_2_93.lix -- repl
Lix 2.93.3
Type :? for help.
nix-repl> builtins.fromJSON ''"\u0000"'' == ""
true

shion:~
❭ nix run nixpkgs/nixpkgs-25.11-darwin#lixPackageSets.lix_2_94.lix -- repl
Lix 2.94.0
Type :? for help.
nix-repl> builtins.fromJSON ''"\u0000"'' == ""
false

unfortunately this does result in an abort with newer Nix versions, so you still need to e.g. if builtins.substring (builtins.stringLength builtins.nixVersion - 4) (-1) builtins.nixVersion == "-lix" then builtins.fromJSON ''"\u0000"'' != "" else false.

but the Lix versions are at least distinguishable without looking at builtins.nixVersion, so I don't think the argument for not having feature detection for this holds.

another thing you can do is define an attrset with every non-NUL-containing single-byte string, and then do stringContainsNul = s: lib.any (char: !(everythingButNul ? ${char})) (lib.stringToCharacters s).

IMO if computations with NUL bytes were not meant to sneak in to having effects on derivation hashes then it was a mistake to start allowing them… if they're going to be allowed, at least a builtins.stringContainsNulByte or (_: false) seems reasonable so that library code can work correctly with all strings that could be passed to a library function on a given implementation without such contortions. (but of course you can always sniff builtins ? stringContainsNulByte for a strong correlate of how that builtins.fromJSON call will behave if you really want.)

In reply to @whispers:catgirl.cloud
lix calls it pipe-operator, nix calls it pipe-operators