Null-Terminated Strings

Sorry, strlcpy is a failure. It takes more and uglier code to use it correctly than to use strcpy with the same level of checking. As a consequence, it is rarely used correctly, and unprofitably when it is. This is not to say that one cannot improve on strcpy, just that strlcpy doesn't.

nul terminated strings have a huge problem: you can accidentally overwrite the nul, and then you're dead. But if you're doing that, you can accidentally overwrite bits of the inside of the string as well, and then you have wrong results! Is that better? Probably not. Oh, and overwriting off the start or end can break your memory allocator or stack frame anyway, so you'd be dead in any case, even if not using nul-terminated strings.

And then we have Pascal-layout strings (as opposed to actual Pascal 'strings', a nightmare for other reasons, see Kernighan). They don't fix this problem (you just have to overwrite the start of the string, not its end) and have two much bigger problems: finite string length, and an increase in size of every string. The finite string length means that writing general string-handling algorithms without special cases for the rare event of large strings is impossible, and the increase in size of every string bloats small strings, which are by far the common case. You can patch both of these: the first, by making the finite string length as large as a pointer; and the second, by noting that alignment constraints in existing systems bloat the effective size of strings anyway. But of course this soon turns into a special case of nul-terminated strings: point the pointer at the end of the string, bingo, one rather hard-to-consult nul by any other name.

The biggest downside is probably a long-term ABI problem. The scheme is inflexible. If your Pascal string-length header is too short, however do you expand it? It's wired into every string-using program out there! At least nul-terminated strings need no expansion.

The real solution to string-handling unfortunately requires a VM of some description which can prevent the program from accidentally overwriting fields in aggregates by writes to any other field or variable. Then you can do reliable Pascal strings, separating the length from the content, or reliable null-terminated strings, with the separate compartment containing a pointer into the string. Unfortunately this is incompatible with low-level all-the-world's-a-giant-arena languages like C without very specialized fine-grained MMU hardware.

(I have, like everyone, written my own dynamic string-handliing library when younger. It starts out simple but it's amazing how soon you have to introduce extra code to track pointers and make freeing them in error cases less verbose, and extra code to track memory leaks... you need that in C anyway of course but the massive increase in dynamic memory use that dynamically allocating most strings brings tends to force them on you sooner than otherwise.)

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.

> I actually think nul terminated strings are simple and elegant and work.

And you can also combine them to do things like:
enum {lang_english, lang_french, lang_german} current_language = lang_french;
const char mltstr_language[] = "english\0francais\0deutch\0"
const char *curlang(const char *mltstr)
{
/* select the right sub-string depending on current_language */
}
void fct(void)
{
printf ("LANG=%s", curlang(mltstr_language))
}
It saves *a lot of space* ; having strings, (aligned) pointers arrays everywhere, and worse having (aligned) size for pascal strings takes easily more memory than the program code and data altogether.