Re: strlcpy and strlcat in linux libc ?

[elf@buici.com]

I'm a little confused by your comments and would appreciate
clarification. 


On Mon, Mar 04, 2002 at 02:50:45PM -0800, Joseph Carter wrote:
> On Mon, Mar 04, 2002 at 03:16:33PM +0100, Moritz Schulte wrote:
> > > I am working at the moment on some port from openBSD to debian, and
> > > discovered that they use this strlcpy|cat (security enhanced version
> > > of strNcpy|cat). Does someone know if there are any plan or a place
> > > to get those included in the standard version of the libc ?
> > 
> > Get an impression:
> > 
> > http://sources.redhat.com/ml/libc-alpha/2002-01/msg00001.html
> > http://sources.redhat.com/ml/libc-alpha/2000-08/msg00052.html
> 
> Nice to see good old anti-Theoism influencing excuses to ignore code which
> makes perfect sense.

As long as there are no toungues in cheeks, you seem to think that
strlcpy is better than strncpy.

> 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?

> 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?


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

Cheers.