Re: strlcpy and strlcat in linux libc ?
On Mon, Mar 04, 2002 at 04:11:25PM -0800, Joseph Carter wrote:
> 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.
Are these stated anywhere? I didn't read the mail archives referenced
at the beginning of this thread, I'm using my memory of a disussion
on glibc-dev (and cross-posted to hell and back :). One of the reasons
I saw for not including these functions was that they were underspecified,
and the specification (i.e. manpage) would have to be deduced from the code,
which wasn't the same in all implementations.
> 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.
... and strlcat returns the sum of the lengths of the strings, even if
that didn't fit in the destination buffer. That's why the function was
called inefficient -- the implementation has to scan the entire source
string, even if it doesn't have to copy all of it, for the sake of a
rarely used return value.
> 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.
It's still less efficient than knowing how long the string is in the first
place, though.
You seem to be comparing strl* to strn*. Well, the strn* functions have
unfortunate interfaces and just about anything would be better, including
the normal str* functions combined with judicious use of strlen. I think
that is what you should be comparing strl* to.
> 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
I saw some other reasons stated, namely:
- The functions are not well specified.
- They make security worse by encouraging converting str* and strn*
code to strl* code, instead of paying proper attention to string lengths.
- Including them in glibc would not help portable programs, which would
still have to include their own copies anyway.
I also saw another reasons in favour:
- Including them in glibc means they can benefit from the same
processor-specific optimizations that strcat and friends enjoy.
(Note that I don't necessarily agree with any of these, I'm not well
enough informed for that. I'm just saying that these reasons were
stated and argued about.)
> While I'm not likely to argue on the third point (except out of rampant
> paranoia that it's possible that maybe you could get a printf to feed you
> output that you as a user should not be able to see, maybe a passwd or
> something?),
I'd like to add that truncated strings can be a significant security problem.
Example: Consider a program that has a function to check a URL for "bad
characters" before passing it on to another program. This function first
decodes the URL. Unfortunately the decoding function uses strlcpy into
a 1024-byte buffer, so that bad characters beyond the 1024th are never
even seen.
The way to fix this is to allocate the buffer dynamically, or signal an
error if the URL is too long. In both cases the strl* functions are not
needed.
> the other two reasons are not really reasons - they're BSD
> bashing. While I have tons of reasons to bash BSD, OpenBSD particularly,
> the strl functions are not among them.
The thread I saw (which may not be the same one you've read) included
a scan of openssh code for places where strl* functions were put to
good use. So it wasn't as knee-jerk as all that.
--
Richard Braakman
Will write free software for money.
See http://www.xs4all.nl/~dark/resume.html
Reply to: