~luxferre/nntrac

5bd1524917a0589ef1a89ceb4d69df42f2d40f59 — Luxferre 6 months ago 2535dab
rdm fx
1 files changed, 6 insertions(+), 0 deletions(-)

M README.md
M README.md => README.md +6 -0
@@ 174,6 174,12 @@ Because this is probably the only functional scripting language that can be full

While having more "batteries included", T-84/T2001 had diverged from the original elegant design by switching to name suffixes to decide what to do with the function return value. This is much less flexible and less convenient for large-scale programs. T-64, on the other hand, can be easily extended (when really necessary) to do all the same things as T-84 allowed out of the box without sacrificing its core simplicity and flexibility.

### Is nntrac binary-safe?

In general, no. All nntrac programs are expected to not contain null bytes and the bytes from 248 to 255. Since nntrac, like all other TRAC dialects, is fully homoiconic and any piece of data can be treated as code, your data must not contain these bytes either. Emitting bytes with these values using the `av` primitive can and most probably will result in undefined behavior.

To process arbitrary binary data in nntrac script, it is mandatory to convert it into readable format (like hex or dec) with external tools (like `od` or `xxd`) before feeding it to the script. The nntrac interpreter contains all features required for your script to be able to process this kind of data.

### Is nntrac UTF-8-safe?

Mostly. All the internal meta characters are chosen so that they never occur in any valid UTF-8 sequence. All primitives, however, operate on individual bytes, so the primitives that allow you to input/output/manipulate a single byte or some numbered bytes are not UTF-8-safe. These include `rc`, `cm`, `cc`, `cn`, `ac` and `av` primitives.