Does it not give an easy fuzzing attack? For anything that parses an input stream, the presence of nul bytes in that stream can lead to very unpredictable results unless one is really careful. Additionally, it is painful to have a string version (str) and a byte array version (mem) of everything, especially with a richer API (e.g. splice(), substr(), squash()). I've come to the conclusion that keeping length alongside the array is the only sane solution. Perhaps that already commits it too much down one path, so that it does not properly belong in the C library. By now I think the best is to have a byte-array API, and leave it up to the user of that API whether they want to keep it C-string compatible. If the keeping-length overhead is unacceptable, it is possible to do the string manipulations painlessly with the more generic API, and isolate a classic C-string as the very last step.