Not trying to be a troll, but is this benefit anything more than having to carry two variables? As in, is this about getting the length without having to use str Len even once?
If it's part of the type, then the compiler can automatically insert bounds checks. If not, then you'll have to insert the checks manually, which we both know won't happen.
Another trouble with two variables is there's no obvious connection between them. One can be modified without the other, etc.
Obviously, a struct is one option. The problem is that you then need to make a whole string library. Thankfully, many exist, so this is a non issue, unless there's a requirement that you write all the code yourself.
> A struct won't be recognized by the language in order to automatically insert array bounds checks.
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.
Sure. The C Standard library relies on 0 terminated strings. The Linux API relies on 0 terminated strings. Every C library I've every used relied on 0 terminated strings for its interface.
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.
> 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.
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.
Just record it once