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.
Embedded has enough memory buffer manipulations to be a concern as possible CVE root causes, specially in the IoT age where the S stands for security.