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] Implement strlcat [BZ#178]

On 12/11/2015 04:09 AM, Florian Weimer wrote:
This implementation comes with documentation and it says

My comments were about the OpenBSD implementation, not the documentation. If implementation compatibility is required (which I think was Zack's point), we need to fix incompatibilities with the OpenBSD implementation, even if these incompatibilities aren't documented.

Conversely, if implementation compatibility is not required, then we needn't reproduce OpenBSD's behavior exactly on weird corner cases that come up only with buggy applications. NetBSD does this to some extent, and if we're going to implement strlcpy+strlcat at all, we could do so as well. So, for example, it would be fine if _FORTIFY_SOURCE caused strlcpy to report an error when given overlapping arguments, even though OpenBSD's strlcpy implementation has well-defined behavior in that situation.

Either approach would be better than a randomish glibc implementation, partially compatible with OpenBSD's weird quirks and partially not, with no principle for when we're compatible and when not.

âIf the src and dst strings overlap, the behavior is undefined.â


If the goal is to implement this spec (and implementation compatibility is not required), then this quote says the destination is a string, which means the destination buffer is null-terminated for strlcat, and also means SIZE is nonzero for both strlcpy and strlcat. And that is what my proposed strlcpy+strlcat doc patch says, albeit more clearly. Of course other parts of the OpenBSD spec talk about what to do when SIZE is zero or the strlcat destination is not a string, but what can I say? The OpenBSD spec is confused and contradicts itself, and this gives us wiggle room to interpret it reasonably for these weird corner cases.

Thanks, by the way, for being so patient with all this. This API is such a pain.

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