[PATCH v7] Implement strlcpy, strlcat [BZ #178]

[Paul Eggert]

Alexander Cherepanov wrote:

> it's handy

No, because even if that example's silent-truncation bug were fixed (which is 
yet another bit of evidence against strlcpy!), its use case is already 
well-addressed by the standard API, and portable programs can (and already do) 
use something like the following instead.

   void
   cpy_with_growing (char **dest, char const *src, size_t *size)
   {
     size_t s = strlen (src) + 1;
     if (*size <= s)
       {
	free (*dest);
         size_t doubled = 2 * *size;
	*size = s <= doubled ? doubled : s;
	*dest = xmalloc (*size);
       }
     memcpy (*dest, src, s);
   }

> you can catch size=0 with strlcat even if strlcpy accepts size=0 without triggering any protections.

No, because often only strlcpy is executed, with strlcat used only in relatively 
unusual circumstances. There are sound software-engineering reasons for 
insisting that strlcpy be no less reliable and strict than strlcat, and for the 
two functions to follow the same rules.

> be conservative in what you document, be liberal in what you implement.

Yes, that's a goal of my most recently-proposed documentation. Again, I don't 
think we should add strlcpy+strlcat to glibc; but if we do add them, we should 
document them conservatively.