Re: [PATCH 1/2] Implement strlcpy and strlcat [BZ #178]

[Florian Weimer <fw@deneb.enyo.de>]

* Alejandro Colomar via Libc-alpha:

>> +  size_t src_length = strlen (src);
>> +
>> +  /* Our implementation strlcat supports dest == NULL if size == 0
>> +     (for consistency with snprintf and strlcpy), but strnlen does
>> +     not, so we have to cover this case explicitly.  */
>> +  if (size == 0)
>> +    return src_length;
>> +
>> +  size_t dest_length = __strnlen (dest, size);
>
> The OpenBSD contract of strlcat(3) includes that _both_ the source
> string and the destination strings are NULL-terminated.  I guess
> POSIX has kept that contract.  If that's the case, we can just call
> strlen(3) here.

NetBSD says this:

| Note however, that if strlcat() traverses size characters without
| finding a NUL, the length of the string is considered to be size and
| the destination string will not be NUL-terminated (since there was
| no space for the NUL).  This keeps strlcat() from running off the
| end of a string.  In practice this should not happen (as it means
| that either size is incorrect or that dst is not a proper ``C''
| string).  The check exists to prevent potential security problems in
| incorrect code.

<https://man.netbsd.org/strlcat.3>

OpenBSD alludes to this as well:

| strlcat() appends string src to the end of dst. It will append at
| most dstsize - strlen(dst) - 1 characters. It will then
| NUL-terminate, unless dstsize is 0 or the original dst string was
| longer than dstsize (in practice this should not happen as it means
| that either dstsize is incorrect or that dst is not a proper
| string).

<https://man.openbsd.org/strlcat>

So I think we should be calling strnlen here.  If we call strlen
instead, we'd have to bound the result.

Thanks,
Florian