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.