This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v7] Implement strlcpy, strlcat [BZ #178]

On 01/05/2016 10:18 AM, Florian Weimer wrote:
We need to compatible with as many of the implementation we replace as possible.

Sure, but any need for bug-for-bug compatibility would not be absolute. A more-important need would be to support applications that use glibc. If glibc applications would benefit from better checking for weird corner cases that BSD man pages say should not happen, the glibc spec should allow such checking even if the BSD implementations don't happen to do such checking now, or do it sometimes but not others.

the size-zero buffer is quite clear from the original description of strlcpy.

No, the original description of strlcpy says "Note that you should include a byte for the NUL in 'size'.", which means that 'size' should be nonzero. The original description also says "The strlcpy function copies up to size - 1 characters from the NUL-terminated string src to dst, NUL-terminating the result.", which means that the result is null-terminated. See:

The original description also contains some contrary wording elsewhere "(as long as size is larger than 0)", but the point is that the spec has *always* been confusing and contradictory in this area. Really, the only safe way for an application to follow the original spec, is to avoid calling these functions with zero sizes.

Granted, the description of strlcpy has mutated and there are now versions floating around that talk about size-zero more consistently, but it is not at all clear that this was prompted by application needs or that applications depend on it or should depend on it. It looks more like a case of library implementers trying to clean up a messy spec without thinking things through carefully enough.

For strlcpy, we don't care if the destination is a string or not because we overwrite what's in the destination array.

No, applications that call strlcpy expect it to create a string. For example, the design intent is for applications to use strlcpy followed by strlcat, and because strlcat (S, ...) assumes that S is a string, strlcpy must create a string in S; otherwise the two functions would not be the companion functions that they're clearly supposed to be.

+The behavior of @code{strlcpy} is undefined if @var{size} is nonzero and
+the source string and the first @var{size} bytes of the destination
+array overlap.
The phrase "@var{size} is nonzero and" is unnecessary, since a
zero-length array cannot overlap anything.
It's okay as far as the formal description of restrict is concerned, but
it's not clear with the informal âoverlapâ.

"overlap" has a standard usage in C11 (one that agrees with the formal description of 'restrict'). The use of the phrase "@var{size} is nonzero and" implies that our use of "overlap" has a different meaning. I suppose we could fix the problem by mentioning somehow that the wording's nonzero restriction is not intended to imply that size-zero objects can overlap anything. However, it'd be better to simply disallow size-zero strlcpy, as in my most-recent proposal.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]