For a while, 16bit would probably have seemed too extravagant. Now 32bit would probably seem too small.
For a “strongly typed” language, C is pretty damn loose where would have mattered.
It has a big advantage over the Pascal approach in that you can do zero-copy slicing, since the length is separate from the actual data.
And `size_t` makes perfect sense for the length here. If your strings are longer than the address space (which `size_t` technically isn't, but is practically very strongly correlated to it), then you're going to have a problem regardless of the number of bits for the length anyway.
But one would note that in order to gain memory for this particular case of slicing, one introduces 2 extra words (size and pointer) for every other cases. Like perhaps the second most common string operation, concatenation. In those other cases, the benefit is slightly negative.
I've had extensive experience with "counted strings" because I implemented a bunch of Forth interpreters which also uses this scheme. Including the common trick of using counted and zero-terminated strings, which is the worst of both worlds in the end. Forth is the kind of language that quickly show you how bad your choices are.
I eventually dropped all that and adopted ASCIIZ strings because they are generally more efficient (if you pay attention to the strlen() performance pitfalls) and having a dead simple interface with the rest of the world (OS, libraries) is more valuable.
And I have my doubts w.r.t. 0-terminated strings being more efficient, with maybe the exception of some very specific niches.
It turns out that the machine is much better at the sort of boring mechanical tasks where thoroughness counts and imagination doesn't and so languages which do more, and more, and more checking pay off very well. Rust's borrowck is the obvious first thought today but say WUFFS will check that you've proved certain key properties, WUFFS doesn't need to insert runtime bounds checks for example because you've proved, before the code would compile, that you don't have any bounds misses. You might have proved it by writing bounds checks yourself of course, or likely you have an inherent mathematical rationale for why your algorithm has no misses, but either way the compiler checked your work.
Bounds checks and sized arrays and strings are mechanically very easy to perform by a machine. These are highly automated tasks.
There are some extreme cases where they ruin performance, but in the vast majority of cases they don't matter.
If you look at the type of tasks that cannot be automated, if going from no to full automation required an efficiency loss of 5%, most people would see taking the hit as an obvious choice.
And this is where the problem becomes recursive. You can build a language where the runtime check becomes a compile time check.
We ought to abandon the C paradigm of shifting all the work to the developer and shift more work to the machine.
Linux already takes several of these "efficiency loss" choices in C. The insistence that "actually I never make this mistake" has to be the surest sign that you're not talking to a real engineer across our whole industry. I associate it most with Bjarne Stroustrup, a man who has written a lot of books and papers but no notable software since his "cfront" C++ transpiler decades ago.
And besides all that, WUFFS isn't even taking an "efficiency loss" - remember it isn't emitting bounds checks it just checks that you proved you don't have bounds misses.