This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FAQ about strlcpy/strlcat ?


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 :-).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]