Did Ken, Ritchie and Brian choose wrong with NUL-terminated text strings? (2011)

In the article he says it is just one byte extra, but that's clearly not the case, since we probably want strings longer than 255 characters. To be practical, even in the sort term, you'd probably need at least two bytes, and that's still a bit limiting. NUL-terminated strings keep you from having to worry about the size of the length specifier and what byte ordering when storing it. He notes that other languages of the day didn't go with…

Worth keeping in mind that the security cost here is illusory: the track record of length-delimited data structures isn't much better than that of ASCIIZ, especially since integer handling in C is so treacherous.

Very good article. There is a huge cultural blindfold that Unix/C have formed indirectly formed on everybody's thinking about computers. Most of us have never used computers outside the Unix sphere of influence. The point about hardware (in this case instruction set) adapting to Unix/C strings is also a recurring pattern, and makes it hader to climb out of the pit of local optimum /path dependence. Fun thought experiment to think how things might have turned out if ideas from…

Null terminated strings always seemed to me like a terrible idea, but on the other hand, 255-character maximums aren't really reasonable. What we need are strings prefixed with a length of the length of the string and then the length as a variable length integer.