Anything that needs strings longer than 255 chars already had a solution in existing systems programming languages
back when C was born.
Character arrays with open length, bound checked.
Naturally it requires better compiler support than C authors were willing to implement.
>Naturally it requires better compiler support than C authors were willing to implement.
Which is still the case with many things in Go, a language of close origin to C (though this time not about strings).
It is interesting how in both cases they disregarded what was being made around them.
What was made around them was only ever the gorilla with jungle thing. Fine for small programs, or larger ones within walled gardens. But not fine for infrastructure work.
Yet Multics was deemed safer than UNIX as per DoD security assement.
I guess security is not relevant as infrastructure work.
Oh, and what do they use today?
> I guess security is not relevant as infrastructure work.
...
I have a feeling that of all axes of performace C cares the most about memory overhead. Then the obvious idea is to have it at exatly one byte per "simple" string, and you get to pick the class of programs that can't get away with that default string type:
• One-byte terminator: complicated text-handling application with a lot of (longer than a couple of pointers on average) string slices.
• One-byte length: anything that needs strings longer than 255 chars.
And then of these two solutions you pick the obviously more general one. What could possibly go wrong?