Conflicting information about NUL bytes #1047
Labels
No labels
Affects/CppNix
Affects/Nightly
Affects/Only nightly
Affects/Stable
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/lix ci
Area/nix-eval-jobs
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/repl/debugger
Area/store
awaiting
author
awaiting
contributors
bug
Context
contributors
Context
drive-by
Context
maintainers
Context
RFD
crash 💥
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
Feature/S3
imported
Language/Bash
Language/C++
Language/NixLang
Language/Python
Language/Rust
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
Topic/Large Scale Installations
ux
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lix-project/lix#1047
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
So we currently have the deprecated feature nul-bytes which turns on NUL byte support vs pascal strings (which fixes NUL byte support, hopefully) that we actively promote as being new in the 2.94 release.
This probably needs more explaining including the future plans for this. Is the intent to drop NUL byte support in strings as it being in "deprecated features" normally means, or do we want to explicitly support them. In that case it probably should not be in deprecated features or at least not without a very good explanation.
this deprecated feature is only about embedding nul bytes as literal NUL in the source. once we have an escape syntax for strings (which
cl/2310is working towards) we will have a good way to produce non-literal nul bytes in strings, until then we'll need workarounds such as json-decoding"\\u0000"and using it as a constant.Then we should still document the relation between the two, it is quite a weird read right now if you actually check.
We may also need a mention of the fact that strings can contain nulls, but there is currently no direct way to create them.
Possibly even mentioning the workaround, though as that is temporary, that may be better left out.