> Thankfully, many exist, so this is a non issue
Many string libraries that are incompatible with each other. This is a huge issue. (I myself made many C string libraries. It's not so easy. Try it.)
The language extension I proposed for C is the same one D uses. D has had it for 20+ years, and it has proven very, very satisfactory.
If you want automatic bounds checks, then C is not the language for you.
> This is a huge issue.
Could you give an example where it's a huge problem? I'm probably limited by my experience. All of the codebases I've worked on used a single string library. When passing externally/to other libraries, boring C interfaces were used, then those libraries do what they wish from there. The string libraries I've used were mostly, deep down, just structs, with a length member, char pointer member, and encoding stuffs. Passing to the other library almost always ended up just being those member values being passed as arguments to a function, which were copied to the nearly identical structs of the other string library.
So you use a translation layer. Sorry, I just don't like them, but if you're fine putting these on all your interfaces with other libraries, well, what can I say? :-)
> If you want automatic bounds checks, then C is not the language for you.
I would reframe that as: "if you're ok with buffer overflow malware injection, then C is the language for you!" Nobody has yet figured out how to stop that.
The sad thing is it's so fixable with just a minor, compatible change to C.
Write manual bound checks and good code in general? Granted you won't be able to catch every vulnerability, but at some point other vectors are so much easier to exploit that you won't have to worry about these anymore.
I promise I'll write good code from now on. Scout's honor.
40 years of C buffer overflows argues that doesn't work.