Implement C11 annex K?

[Paul Eggert]

David A. Wheeler wrote:

> I'd like to convince you to think about *risk*.

I had already thought about it.  There's no evidence that using strlcpy 
reduces risk significantly, compared to spending an equivalent amount of 
effort using standard alternatives.  If anything, the little evidence 
we've seen indicates the contrary.

Most of your email was about *style*, not about *risk*.  Style arguments 
are a recipe for endless dispute, which I'd rather avoid; so I'll let 
you have the last word on style preferences.  Going onto the technical 
points:

>>> addrmatch.c:321:
> The spec says snprintf can return <0, which this code fails to handle.

In general snprintf can return <0, but this call won't.  And even if it 
did, it wouldn't be a problem in practice, as Rich Felker mentioned.

>>> auth.c:486:
>>>   strlcpy(buf, cp, sizeof(buf));
>>>   ... So.. do you really believe that MAXPATHLEN really is the max length?
>>

>> ... this use of strlcpy has undefined behavior ...
>
> I don't think so.  strlcpy is required to copy the source left-to-right

The OpenBSD man page for strlcpy disagrees with you; see 
<http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/strlcpy.3>, 
which says "If the src and dst strings overlap, the behavior is 
undefined."  If strlcpy were standardized no doubt the same language 
would apply, as it's de rigueur for the string functions.

For the other three calls to strlcpy, you raised only style-based 
objections.

So, on a technical basis we have the same results as before: of the five 
strlcpy calls you brought up, one call can have undefined behavior, one 
call does silent truncation, and the other three do not fix any bugs 
compared to using standard routines.

To be honest, I was surprised by these results: I didn't think strlcpy 
would be this strikingly bad.