Deep in the comments, 'slibc' is mentioned. I hadn't known about it, but this library provides str..._s() implementations of all the standard str...() functions as defined in Annex K of the C11 standard (which I also hadn't known about).<p><a href="https://code.google.com/p/slibc/" rel="nofollow">https://code.google.com/p/slibc/</a><p>At a glance, this seems like a better solution than any of alternatives: require the buffer length to always be specified, and call a user controlled handler instead of allowing an overflow. This handler defaults to abort().<p>While there are fine arguments to be made for using a real string library like bstring, are there downsides to the str_s approach compared to using the str, strp, or strl family of functions?
I usually use strncpy and enforce null at end, that virtually is the same that does a strlcpy.<p>But if you know how long is the source and destiny buffers (and if you are using str[nl]cpy, probably you know it), you could use memcpy and get a much more faster copy.
Safe string handling in C <i>can</i> be done, but not with char*.<p>PHP's Zend Engine has safely-handled strings, for example, but we do that by reference-counting them and having an explicit length.
I agree with drepper on this; it's a solution in search of a problem. You should either know WTF you can accept or use a higher level construct that can resize. Silent truncation seems bad - truncation attacks are a real attack vector that SSL, for example, tries to prevent.
I am curious why strlcpy() was not modified to check the length going in and out to check for truncation? I am not a C/C++ guy but that is one question I had when he said that was one of the gripes for the function.
> The primary complaint about strlcpy() is that it gives no indication of whether the copied string was truncated or not.<p>So how hard would it be to add a return value indicating this?