This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Implement C11 annex K?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Russ Allbery <eagle at eyrie dot org>
- Cc: <libc-alpha at sourceware dot org>
- Date: Thu, 14 Aug 2014 00:55:42 +0000
- Subject: Re: Implement C11 annex K?
- Authentication-results: sourceware.org; auth=none
- References: <E1XHe8v-0004Ur-Hp at rmm6prod02 dot runbox dot com> <Pine dot LNX dot 4 dot 64 dot 1408132054090 dot 16622 at digraph dot polyomino dot org dot uk> <53EBD7D9 dot 1040008 at cs dot ucla dot edu> <20140813213520 dot GQ12888 at brightrain dot aerifal dot cx> <53EBEACD dot 3070000 at googlemail dot com> <87k36cc559 dot fsf at windlord dot stanford dot edu>
On Wed, 13 Aug 2014, Russ Allbery wrote:
> If the answer is "use strcpy and strcat because this code is provably
> correct with them," I guess I understand your position, but if I somehow
stpcpy is better than strcpy and strcat here; repeated strcat, or strlcat
as in your code, has quadratic overhead repeatedly looking for the end of
the string being built up, whereas stpcpy returns the end pointer for use
in the next stpcpy call. However:
> messed up the length calculation logic, I would prefer to truncate the
It's not obvious what a safer version of the stpcpy code would look like,
and the length calculation logic fails to allow for the sum of the lengths
exceeding SIZE_MAX (e.g. from a long separator, or from several pointers
to the same long string in the vector) (so resulting in buffer overflows
from any version that doesn't check each write fits in the remaining
space). (This size calculation as written could feasibly overflow even on
a 64-bit system; many such overflows are only realistic on 32-bit
systems.)
--
Joseph S. Myers
joseph@codesourcery.com