Conflicting information about NUL bytes #1047

Open
opened 2025-11-22 21:45:03 +00:00 by helle · 2 comments
Member

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.

So we currently have the deprecated feature [nul-bytes](https://docs.lix.systems/manual/lix/2.94/contributing/deprecated-features.html#dp-feature-nul-bytes) which turns on NUL byte support vs [pascal strings](https://git.lix.systems/lix-project/lix/src/commit/7e193f962e35217268e81164eef9f8be7059a84e/doc/manual/rl-next/pascal-strings.md) (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](https://docs.lix.systems/manual/lix/2.94/contributing/deprecated-features.html#lifecycle-of-a-deprecated-feature)" 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.
Owner

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/2310 is 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.

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/2310 is 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.
Author
Member

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.

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](https://docs.lix.systems/manual/lix/2.94/language/values.html#type-string) 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.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lix-project/lix#1047
No description provided.