alt Hacker NewsPartly agree but there would have been squabbling on the data type of the size, unless it was variable length. The latter would have had other issues too.
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.
Replies
C is a weakly typed language. It’s statically typed, which is a different thing
No, there would not have been and this is most likely not the reason. size_t exists for precisely this use case. It has existed since C89.
I don't think 32 bits for the size would be too small. That would max out at a 4GB string, which is large enough that even today it's a big red flag saying "what are you doing bro, reconsider your approach". I can conceive of a string larger than 4GB, but I can't conceive of a situation where it's reasonable to use one.
I like the D approach where arrays are just `struct { size_t length; T* ptr; }` internally --- and strings are just arrays of `immutable(char)`.
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.