This is the mail archive of the
mailing list for the glibc project.
Re: The semantics of strlcpy and strlcat
- From: Russ Allbery <eagle at eyrie dot org>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 21 Jan 2016 22:54:32 -0800
- Subject: Re: The semantics of strlcpy and strlcat
- Authentication-results: sourceware.org; auth=none
- References: <CAKCAbMhfFmfdrVB7_FovQmfrbAAXjKmis3-JWnD1qDEODi_gQg at mail dot gmail dot com>
Zack Weinberg <email@example.com> writes:
> * Three out of four strlcat implementations have well-defined behavior
> (they return `destsize+strlen(src)` and leave the destination buffer
> unchanged) when the destination buffer does not contain a terminating
> nul. The other one blindly calls strlen() on the destination buffer,
> and I very strongly suspect that this is an oversight.
As the author of the implementation that calls strlen() on the destination
buffer, I can confirm that its specific behavior was an oversight. I
never gave the slightest bit of thought when writing this implementation
of what would happen when strlcat() was called with a destination string
that wasn't a nul-terminated string. I have no opinion on what the
correct behavior should be.
Previous discussions here have convinced me that these interfaces are a
generally bad idea. I no longer use any of these functions in any new
code and have been slowly excising them from all of my software.
I'd like to remove them all from INN as well. Unfortunately, INN is a
very old code base that's riddled with buffers of fixed size allocated off
the stack with unclear object lifetimes and no further thought given to
any form of memory management, which makes it hard to take the approach
that I'm using with all other software I maintain (switching to asprintf).
Short of a grand removal of static buffers that's an immense amount of
work and may not happen for software that's mostly in maintenance mode,
I'm not sure what the best solution is. (I stand by my original feeling
that silent truncation is generally better than silent buffer overflows,
but that's a little like saying that tuberculosis is better than ebola.)
In the meantime, I'd be happy to see well-thought-out versions of these
interfaces appear in glibc to replace my poorly-conceived hacks and
upgrade at least the predictability of this code. From my perspective,
it's almost irrelevant what the precise semantics are. The people in
these threads have already clearly given the matter much more thought than
I did originally.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>