That is a problem with the stdlib and not so much the language. There is nothing stopping you from creating a more robust string implementation that stores size and does bounds checking for some operations(You can't easily/safely enforce anything like string immutablity at the language level... unless anyone out there can think of a way). I've seen it before, but not often. Usually the C code I'm working on does very little string manipulation and speed/size matters.
Well, to be fair, strings are much nicer to work with when you have a suitable overload for '+', and that very much is a problem with C the language. Same goes for 3d vectors in C as well.
That's your opinion. I (and many other C programmers) find it refreshing that when I see a "+", a couple numbers are going to be added together. Nothing else could possibly happen, and I don't have to cross-reference the types of the operands to figure out whether a method in some far-off source file is going to be called.
C is willing to hide a lot of numeric type casting details about doubles vs floats vs unsigned ints vs chars behind the magic of the "+" character, so maybe you're willing to endure a lot more type-dependent compiler magic than you're letting on here, despite so graciously speaking for many other C programmers. In fact, "p+1" might very well mean "p+4" if p is an int. Or maybe it means "p+32" if p is a FILE (on my compiler). Or maybe it means... Wow! Wait a second! That seems pretty type dependent to me, come to think of it! But that's just my opinion.
Look back; I never said the + operator wasn't type dependent. It clearly is. It's certainly true in C that no matter what, the + operator adds two numbers together. The exact nature of that addition depends on the types of the operands, but the rules for that are dead-simple, and most importantly, aren't extensible; I can't include a header file that will change those simple rules.
i.e. Once you understand how pointer arithmetic works, and you know how C's type promotion scheme works, the meaning of any addition expression is basically evident, and you have a few guarantees about the behavior of the program (for example, I can reasonably expect that my addition won't take more than a couple clock cycles, depending on what kind of casting needs to be done and the like). In languages that support operator overloading, + can literally mean anything.
BUT clearly there is a world of difference between saying "it would be nice to have char* + char* as a short hand for string concatenation somehow" - which is roughly what I was saying - versus saying "all operators in a language should be arbitrarily overloadedable", which is roughly how you responded.
Now, I'm not saying there is an obvious way to handle "char* + char" meaningfully or safely in C. But on the other hand,
char stackString = "some literal";
is generally handled in an entirely different fashion from
int myVar = 7;
if both are declared as local stack variables - and C programmers generally have no problem learning that "=" is going to mean something quite special when declaring string literals this way, compared to other data types. Because as you say, it's just one more language rule.
The only real places where I miss operator overloading in C are when dealing with strings in performance non-critical places, any time I'm using 3D vectors, and any time I'm writing matrix math. If those were handled as primitives in the language (and as the string literal example shows, C already does go partway down that road), I'd very happily part with arbitrary operator overloading.
Uh, in what way is that "entirely different" from the int declaration? In both cases, you're just copying a couple words from one place to another, which is what the = operator does. There's nothing "special" about that declaration; we're just writing a pointer into a variable on the stack.
My feeling is that you're uncomfortable with C's treatment of strings because you don't entirely understand the memory model.
