Re: strlcpy and strlcat in linux libc ?
On Mon, Mar 04, 2002 at 04:11:25PM -0800, Joseph Carter wrote:
> > > I don't know how these functions have any effect on security over the strn
> > > functions except in the most indirect manner, but can anyone tell me what
> > > the point of not copying a string past the end of the space allocated for
> > > it is if the next time you attempt to use the newly copied string you run
> > > right off the edge of the new array?
> >
> > Here is where I run afoul. It makes sense to me that these functions
> > are much less interesting for any perceived security impact than for
> > their potential to improve performance. What are you asking here
> > about running off the end of an array?
>
[deletia]
The differences between the two (string) functions are easily
discerned. I suspect it is your word choice that confused me.
> > > But somehow, s/n/l/ in the function name is harder to read and the
> > > function is "inefficient BSD crap".
> >
> > What do you mean here? Is it that strlcpy is less efficient than
> > strncpy?
>
> So say the glibc people in the threads referenced. If the implementation
> is flawed, that should be fixed. The preconditions, postconditions, and
> function declaration are a fine improvement, however.
I cannot imagine how an implementation strlcpy is less efficient than
strncpy unless a programmer depends on the zeroing effect in which
case she needs to bzero before strlcpy'ing.
> Also, notice that strncpy returns a pointer to dest. This is almost never
> used by anyone. I personally have never used it actually. strlcpy does
> return a value, but returns instead the number of characters copied from
> src. This too I use rarely, but whereas strncpy's return value has never
> been even remotely useful to me, strlcpy's has upon occasion.
Of couse. The only reason I can see to return a pointer to the
string is when writing functional-programming style code. Even then,
it doesn't really make sense in C.
> Also, since copying the string also calculates how long the string shall
> be, this strlcpy is _more_ efficient than following the strncpy with a
> strlen (dest), all other factors considered equal.
> > > The only real controversy here is between the status quo and possibly
> > > inflating Theo's ego further (if such could actually be accomplished
> > > anyway.) In the meantime, most of my work (and a lot of other people's as
> > > well) will continue to reinvent the wheel while the glibc maintainers
> > > continue to cover their ears and hum REAL LOUD.
> >
> > Insinuating that glibc maintainers have neglected to include strlcpy.
> > A valid point unless there is some presently unstated reason to leave
> > these functions out.
>
> The stated reasons that strl functions will not be included are:
>
> - They promote bad or less readable code
> - They are "inefficient BSD crap"
> - They do not enhance security in any meaningful capacity
Ah. The missing piece. The third is obviously a straw man and the
first two are a) matters of opinion, and b) difficult to defend.
Thanks.
Reply to: