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

[Paul Eggert <eggert at cs dot ucla dot edu>]

Alexander Cherepanov wrote:
> Are you seriously arguing for glibc not to comply with C11?

Naaah. And on second thought, my comment was based on a backwards interpretation 
of the POSIX spec: that spec places extra constraints on the implementation not 
on the application. So please forget my mistaken comment about POSIX snprintf.

> descriptions (e.g. [2], [3]) of strlcpy and strlcat refer to C9X or BSD,
> not to POSIX. So it's not relevant to the current discussion.

Yes and no. I think Florian is arguing that strlcpy should act like snprintf, 
and so in that sense it's relevant. However, I agree with you that snprintf is 
not an exact analog and is not a good precedent for strlcpy.

> do you think the fact that @var{to} and @var{from}
> overlap makes the code:
>
>    char s[10] = "abc";
>    strncat(s, s, 2);
>
> is invalid even though there is no overlapping copying?

I don't think strncat is an exact analog for strlcat either. That is, although I 
agree that the strncat example has well-defined behavior in C11, this is not 
precedent for strlcat, any more than snprintf would be. They're just different 
functions, that's all.

For example, it'd be reasonable for strlcpy to verify that every byte in the 
destination array is writeable. That could help catch bugs in programs. The spec 
should not disallow such an implementation.