Re: [PATCH 0/2] strlcpy/strlcat/wcslcpy/wcscat implementation

[Paul Eggert <eggert@cs.ucla.edu>]

On 4/5/23 04:20, Florian Weimer wrote:
> Paul, the Austin Groups issue you raised has been closed.  Do you keep
> your sustained objection to adding these functions to glibc?

Yes, I'll withdraw that objection if we add the functions in a good way. 
Compatibility with POSIX is more important than omitting a misguided 
API, so long as the harm is limited to people who insist on using the 
API despite being warned.

By "good way" I mean the following three things.

1. Fix the manual to agree with draft POSIX (currently it disagrees). 
Also, the manual should mention the same sort of problems for 
strlcpy/etc. that it already mentions for strncpy/etc. - truncation can 
lead to security problems, non-text strings, that sort of thing.

2. Do not implement these functions via memcpy or strnlen or anything 
like that. Just use simple code like OpenBSD's. Preferably just use 
OpenBSD code as-is. Otherwise we have the danger of straying from 
OpenBSD semantics. This danger is already present in the proposed 
patches, which have undefined behavior in rare cases where OpenBSD's 
behavior is well-defined and where draft POSIX specifies the OpenBSD 
behavior.

We don't have time to formally verify or otherwise carefully audit this 
code, so this is no place to bikeshed or optimize. The goal is 
compatibility, not speed. Besides, strlcpy destinations and sources are 
almost always small, so in practice using memcpy etc. will likely be 
slower than just doing things the OpenBSD way.

3. The patch should be more conservative: it should declare these 
functions in string.h only on user request, i.e., only when compiled 
with -D_XOPEN_SOURCE=800 (or -D_POSIX_C_SOURCE=2023mmL) without 
-D_GNU_SOURCE. (We can add a new _STRLCPY_SOURCE macro too if that would 
be helpful, to selectively make these new functions visible.) This will 
suffice for POSIX conformance, and it will help avoid bugs when existing 
applications that already supply their own slightly-different strlcpy 
substitutes are compiled with new glibc: it will give these apps' 
maintainers the ability to decide after their own manual inspection 
whether and when to switch to glibc's strlcpy.

I'll follow up with more detailed comments on individual patches. And 
I'll volunteer to do (1), which is likely the most work anyway. I've 
already done much of (1) and will attach that to my detailed comments.