Looks like you are correct… or not

Posted Mar 24, 2012 13:19 UTC (Sat) by khim (subscriber, #9252) [Link]

Its argument order is *of course* different, and the requirement to not change the destination when the source doesn't fit ignores the only reason why strlcpy() even exists -- as opposed to a macro that calls strlen and memcpy.

You want to imply that strlcpy exist only to introduce subtle security holes? Then the arguments to not include it are quite obviously valid…

Of course you can do something sensible with strlcpy's return value -- you can use it as offset to the end of the string, instead of calling strlcat(), when you want to append something.

Right. But the point is that you should not do that. Low-level functions like memcpy, strlcpy, or strcpy_s only make sense when you deal with buffers of fixed size. If you need/want to deal with reallocation and other similar tricks then the whole thing becomes so fragile that it must be put either in separate set of functions or in language core.

NB: *its interface. :-P

Yes. A horrible one. Good API must not only be easy to correctly use, it must be hard to misuse. strlcpy does so-so on the first requirement and completely blows up the second while strcpy_s is fine on both fronts.