This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Implement strlcat [BZ#178]
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 7 Dec 2015 13:05:22 -0800
- Subject: Re: [PATCH] Implement strlcat [BZ#178]
- Authentication-results: sourceware.org; auth=none
- References: <56547472 dot 3010302 at redhat dot com> <5654B1FE dot 5020100 at cs dot ucla dot edu> <5654B796 dot 7070302 at redhat dot com> <5656E018 dot 5020608 at cs dot ucla dot edu> <565F211A dot 2030909 at redhat dot com> <56607CD1 dot 3050209 at cs dot ucla dot edu> <CAKCAbMgDMK9wjfNEJYW7e-cN9s5aVhun6V08OXrcOgYKRYF7_g at mail dot gmail dot com> <5660825E dot 9020901 at cs dot ucla dot edu> <CAKCAbMi2zSJRjS=ceg8UvTYY18UrCWysaOFX+OzvKZQfeR9+SA at mail dot gmail dot com> <5660C545 dot 1090805 at cs dot ucla dot edu> <5661A123 dot 9050408 at panix dot com> <5661BD09 dot 5020408 at cs dot ucla dot edu> <5665905E dot 1020608 at panix dot com>
On 12/07/2015 05:57 AM, Zack Weinberg wrote:
I will continue to insist on_exactly_
matching the OpenBSD semantics or else not having these functions at all.
(I agree, as I think glibc shouldn't have these functions at all. That
being said...)
If I understand the above comment correctly, you have at least three
reasons to object to the proposed strlcpy+strlcat implementation.
First, it rejects null pointer arguments.
Second, when arguments overlap it doesn't necessarily have the same
behavior as the OpenBSD implementation. For example, the OpenBSD strlcpy
implementation always has well-defined behavior when source and
destination overlap, but the proposed implementation does not. The
situation with strlcat is more complicated; still, the OpenBSD
implementation has well-defined behavior in cases where the proposed
glibc implementation does not.
Third, the OpenBSD implementation declares strlcpy and strlcat to have
__attribute__ ((__bounded__ ...)), an OpenBSD extension that generates
warnings when compiling with gcc -Wbounded (an OpenBSD GCC option that
is on by default). The proposed implementation doesn't do that so it by
default does not diagnose bugs that the OpenBSD implementation does
diagnose.
When there is no space to write a nul-terminated string into, there is
no such expectation.
Sometimes there *is* space; that is, the destination size is nonzero,
but the proposed strlcat *still* doesn't store a terminating null.
Doesn't this give you qualms? It does me.
if you polled a random sample of experienced C programmers
they would react to that basically the same way they react to being told
that signed integer overflow is undefined, i.e. "that's stupid and the
standard should be changed."
If you polled a random sample of experienced C programmers and told them
that neither strlcpy nor strlcat were guaranteed to null-terminate the
result even when given valid arguments, they would also say "that's
stupid and the spec should be changed". And they'd have a point.
I could be convinced that the OpenBSD semantics are wrong, but only if
you (being the person demanding a change from those semantics)
I'm not demanding any change to the OpenBSD semantics. The OpenBSD
implementation would conform to the spec that I'm proposing. I'm merely
asking the documentation to permit not only the OpenBSD implementation,
but also the NetBSD implementation that catches the stupid mistake of a
null-pointer argument, and an implementation that also catches the
stupid mistake of output that is not null-terminated. It's reasonable to
have debugging implementations that catch stupid mistakes like this.
find a
piece of existing code that can*accidentally* call either strlcpy or
strlcat with a zero buffer-size argument.
OpenSSH 7.1p1 progressmeter.c on a platform where struct winsize's
ws_col member is an int and is -1, so setscreensize sets win_size to
zero, so refresh_progress_meter's call to strlcat(buf, " ", win_size)
has a zero buffer-size argument. Admittedly implausible on typical
environments, but there it is.