This is the mail archive of the 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 ?

Hi -

On Mon, May 21, 2012 at 08:14:05AM -0700, Paul Eggert wrote:
> [...]
> > What errors are strlcpy/strlcat supposed to catch?
> Buffer overruns.  Thanks, I added that to the wiki.

I asked only because the strlcpy documentation I've seen has never
advised that the function is supposed to catch any errors at all, same
as strcpy/strcat.  -D_FORTIFY_SOURCE is a separate consideration:
"-D_FORTIFY_SOURCE can catch many of the errors that these functions
are supposed to catch"

Or perhaps I misunderstood: does the sentence regarding Annex K talk
exclusively about strcpy_s and strcat_s?  If so, criticizing these is
at best counterproductive to criticizing strl*.

> >> [...]  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. [...]
> I'm not sure the FAQ is in the place to go into all these details

If the faq advises snprintf(), strcpy_s() as a substitute for strlcpy,
it should keep its relative inefficiency/complexity comparisons to

- FChE

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