This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] 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: Sat, 31 Oct 2015 16:24:52 -0400
- Subject: Re: [PATCH v3] 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> <20151030164925 dot GG8645 at brightrain dot aerifal dot cx> <563499D6 dot 5080005 at cs dot ucla dot edu>
On Sat, Oct 31, 2015 at 03:37:10AM -0700, Paul Eggert wrote:
> Rich Felker wrote:
>
> >There is a general principle,
> >which needs to be promoted rather than undermined, that a function
> >cannot have side effects/alter the value of objects outside of its
> >documented behavior.
>
> Regardless of whether that is an (undocumented?) general principle,
> this is a user manual not a formal standard. In this particular
> context it's helpful to describe strlcpy's behavior carefully, since
> it's explained right after strncpy's and the reader might otherwise
> easily get confused into the misimpression that strlcpy behaves like
> strncpy except for guaranteeing null-termination when DESTLEN is
> nonzero.
OK, I can agree with this.
> >Requiring the
> >argument to point to "a string" also expresses the null termination
> >requirement. This is the same language used in the C standard for
> >string functions.
>
> Again, the point of the documentation is to be clear and useful, and
> it's helpful to spell things out given the strncpy context.
> (Besides, this is a manual that contains phrases like "it is more
> efficient and works even if the string @var{s} is not
> null-terminated", so it's a bit much to expect the reader to know
> that "string" always means "null-terminated". :-)
Likewise ok.
> >__-prefixed functions should never
> >be a public API intended for applications to use.
>
> Yes, that's fine. My point was about the non-'__'-prefixed name,
> where it appears we agree.
>
> >No, the fortify version should just abort when this contract is
> >broken.
>
> The idea was that this contract should be memmove-based, not
glibc's role here is not to design the contract but to implement the
existing contract precisely. This is because the whole goal of
providing these functions in glibc is to reduce subtle errors from
people reimplementing fallbacks in slightly-incompatible ways, not to
design a new API that we want to recommend people use.
> All in all, I'd still rather not add this poorly-designed API to the library.
Noted.
Rich