I am still convinced that they made the wrong design trade off when it comes to C-style strings. A Pascal-style string with a length prefix byte takes up the same amount of memory as a null terminated string but is immune to buffer overflow and faster to strlen as well. The only time C style strings offer up any advantages are when dealing with a string that is longer than 255 bytes, which given the memory constraints of the era were incredibly rare.
I feel like C-style strings were nearly inevitable given C's array-pointer duality law. Square bracket array operations just translate into simple pointer arithmetic. To have a length prefix byte you'd need to either make the compiler treat char* differently than other arrays/pointers or you'd need to have the programmer always account for the special byte at the beginning of the string.
Also even with 255 limitation, there could be optimizations in place with struct/union, similar to small string optimization done in C++ and modern languages.
However even considering this was a non-starter in PDP-7/11, there is no excuse why since 1989, WG14 never considered adding capabilities to the standard library similar to SDS, or language improvements like fat pointers (There was even an attempt proposal from Ritchie himself).
I’ve wondered if there should be two string types in C, analogous to different length numeric types. Short strings (“tokens”? “words”?) could be Pascal style strings and longer strings (“buffers”) could be standard C-style null terminated strings. I’ve never tried to work this out for real, it just seems to me that one-size-fits-all strings might not be the best model.
I think it would be better to have the string type being the address and length pair. Pascal strings store the length immediately before the data, which is different than what I think is better is to store the length separately.
