This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4] Implement strlcpy [BZ #178]
- From: Rich Felker <dalias at libc dot org>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 3 Nov 2015 22:23:21 -0500
- Subject: Re: [PATCH v4] Implement strlcpy [BZ #178]
- Authentication-results: sourceware.org; auth=none
- References: <56326B79 dot 8070804 at redhat dot com> <563294BE dot 9070105 at cs dot ucla dot edu> <56376656 dot 1000600 at redhat dot com> <20151103161550 dot GP8645 at brightrain dot aerifal dot cx> <56393F6F dot 5070301 at cs dot ucla dot edu> <20151104005637 dot GR8645 at brightrain dot aerifal dot cx> <56397280 dot 4000805 at cs dot ucla dot edu>
On Tue, Nov 03, 2015 at 06:50:40PM -0800, Paul Eggert wrote:
> Rich Felker wrote:
> >the fact that it's wrong is actually essential to
> >some usage patterns like using fgets to read files that may contain
> >embedded nuls.
>
> Thanks, that's a usage pattern I wasn't familiar with. However,
> among other things the glibc manual explicitly says that fgets
> shouldn't be used in that situation, which suggests the ice is quite
> thin here. So even if POSIX says what you are asserting (I haven't
> seen specific citations, so I'm still skeptical), as a practical
> matter applications should not assume that irrelevant bytes in
> output buffers are preserved.
Not even POSIX is needed for this; it's merely ISO C:
"The fgets function reads at most one less than the number of
characters specified by n from the stream pointed to by stream
into the array pointed to by s. No additional characters are read
after a new-line character (which is retained) or after
end-of-file. A null character is written immediately after the
last character read into the array."
n is merely a bound on the number of characters to be read; while the
buffer is usually at least n characters long, there's not even a
requirement that it need be; for situations where the application
controls the contents of a file, the behavior could be well-defined
even if the buffer is smaller than n.
> As far as strlcpy goes perhaps the manual should merely say that
> it's unspecified what happens to destination bytes after the
> trailing NUL. We can always specify it later, should POSIX make
> things clear. I doubt whether applications care much one way or
> another.
There's certainly existing code that relies on strcpy not clobbering
anything past the strlen(src)+1 bytes it writes. Naturally strcpy
_can't_ do this because it has no way of knowing the dest buffer size.
But to be able to use strlcpy as a safer drop-in replacement in such
code, it would need to preserve this property.
Rich