The better answer would be to add data types like SDS[0] to the standard library, and use them as ADTs (Abstract Data Types) [1].
Unfortunely WG14 has proven in 30 years of existence, that it isn't something that they care to fix, and while 3rd party solutions exist, without vocabulary types on the stardard library adoption will never take off.
It is not as well known, but I just saw a recording of a guy named David Weston, giving a talk called "Default Security" at BlueHat IL 2023, and he talks about how Windows is porting core components over to Rust, and there's in fact already a syscall implemented in it. It's not just Linux!
I don't even see it as unfortunate. It's just reality. It's a tool to be used when appropriate, like any other.
My point is that adding a higher level abstraction for e.g. strings in C runs a strong risk of not being fit for purpose for the people who reach for C.
People code in C because they have very specific requirements. If they could just pick up an opinionated library then it's likely that they don't need to use C in the first place.
> People also have to code in C when no other alternative is possible, or allowed
That's exactly what I said.
> exactly because of that, C security model must be improved.
I'm all ears. For 75 years we've been trying to perfect the need for control with higher level save abstractions.
Most coding nowadays will gladly sacrifice this control, because the code will run in an operating system, and on a fast CPU. And rightly so.
A lot can be gained (without losing control) just by allowing some features of C++. But still, it's not like std::string is a simple fix to this problem. Some C environments cannot allocate memory, or if they can then they need to have an upper bound in how much memory they will allocate.
It's possible to have a mystring type that satisfies the environments like the ones I (and then you) mentioned, but by their nature (because they chose C) they have specific requirements that it may not be possible to solve the general case for.
That said, is strlcpy() a safety improvement over strcpy() and strncpy()? Well... it's not worse. But I'm not sure "if (s >= strlcpy(dst, src, s)) {...}" is any safer than "if (strlen(src)>=s) {...} strcpy(dst,src)". Both are (unless I made a typo) correct, and both are very easy to make a typo with.
And you need to do this at every call site, or you have a bug. Yes, the strcpy() version is much more likely to be exploitable, but the strlcpy() version at the very least produces incorrect output.
And I would not consider something that produces incorrect output "safe". "So just call it correctly" also applies to strcpy(), so same thing.
But yeah, strncpy() was clearly misdesigned, and probably most people would incorrectly guess that its semantics are that of strlcpy(), the latter semantics making sense.
Yes, they make it harder to get memory corruption. But that's a very narrow definition of "safe".
If you tell the computer to copy a string, or append to a string, it's wrong, and not safe, to only do a partial copy or concatenation.
It's a huge footgun. Smaller than strcpy(), sure, but "safe" it is not.
I don't really have a better answer for C.