Re: FAQ about strlcpy/strlcat ?

[William Park <opengeometry at yahoo dot ca>]

On Mon, May 21, 2012 at 08:14:05AM -0700, Paul Eggert wrote:
> On 05/21/2012 07:23 AM, Frank Ch. Eigler wrote:
> 
> >> [...] Also, compiling with gcc -D_FORTIFY_SOURCE can catch many of the 
> >> errors that these functions are supposed to catch [...]
> > 
> > What errors are strlcpy/strlcat supposed to catch?
> 
> Buffer overruns.  Thanks, I added that to the wiki.
> 
> >> [...]  Unfortunately, in practice these functions can cause trouble,
> >> as their intended use encourages silent data truncation, adds
> >> complexity and inefficiency [...]
> > 
> > What complexity & inefficiency is this referring to? 
> 
> strcpy (A, B) is simpler than strlcpy (A, N, B): the extra argument is one
> more thing to program and one more thing to get wrong.
> 
> strcpy (A, B) is also more efficient than strlcpy (A, N, B), in typical
> cases, for both the caller and the callee, since there's no need to
> pass N around or to do runtime checking against N.
> 
> strcpy_s (A, N, B) is typically less efficient than strlcpy (A, N, B),
> as strcpy_s is required to check that A && B && 0 < N && N <= RSIZE_MAX
> && strnlen_s (B, N) < N && ! (A < B + N && B < A + N), and to do almost
> nothing if the check fails.  The strnlen_s check is the killer.
> 
> I'm not sure the FAQ is in the place to go into all these details
> (unless perhaps we have a separate page devoted to strlcpy :-).

Could you reconsider?  I don't think strcpy() is ever used in its raw
form because of lack of destination size.  In practice, two strings are
never the same size, even if they are guaranteed to terminate.  Forcing
every C programmer to build up his/her own functions would be efficient,
no?

Maybe, people are objecting to the name and argument order.  How about
changing it to sntrcpy(dest, sizeof(dest), src), taking cue from
snprintf()?
-- 
William