I think it's not genuine to describe the behavior of strlcpy() as "silently truncating". strlcpy() is documented as "If the return value is >= dstsize, the output string has been truncated. It is the caller's responsibility to handle this."
Careful! Errno can be set even when there is not an error.it's value is only relevant when the return value of the function indicates an error.
That said there are some functions where the possible return values can't indicate an error. In those cases errno should be set to zero before the function call and then a change during will alert you to an error.
Why it's like this I have no idea but it's pretty annoying.
> Why it's like this I have no idea but it's pretty annoying.
The bit about errno possibly being non-zero but not indicating error unless the function does? I guess because the called function can itself call functions / libs which set errno and properly handle those (or just not care). Without the "errno only has meaning if the function returns error" guard, every single function needs to always reset errno to zero before returning, which is annoying and will almost certainly not happen in the majority of cases.
When the function has no way to communicate error, there is no other option but to use errno. But it's good that it's the exception, I imagine.
Ok, but, we've already got that kind of foot-shooting enabled by strncpy(), and glibc can't remove it as it is part of ISO C. If glibc must contain a truncating string copy, I'd much rather have strlcpy than strncpy. Do you find that persuasive?
This is spot on. There are very few cases when silently truncating a copy of a string is an OK thing to do.