Re: [PATCH v4] Implement strlcpy [BZ #178]

[Rich Felker <dalias at libc dot org>]

On Tue, Nov 03, 2015 at 03:12:47PM -0800, Paul Eggert wrote:
> On 11/03/2015 08:15 AM, Rich Felker wrote:
> >I do think this is
> >guaranteed by other implementations, in terms of both actual behavior
> >and the implicit requirement not to clobber memory the function is not
> >specified to clobber.
> 
> I don't see any such implicit requirement, so I agree with Florian here.

In that case, strlcpy can also assign environ=NULL and change the
disposition of all signal handlers to exec /usr/games/hack.

Jokes aside, a function that can have random side effects aside from
what it's specified to do is unusable.

> My impression all along has been that when a function is given an
> output buffer, it can write whatever it likes to the output buffer,
> so long as the buffer has the proper value when the function
> returns.

This is not the case, at least not for any of the standard functions.
Read the specifications. There is no text allowing such behavior.

> In particular, the caller can't expect the buffer's
> irrelevant bytes (i.e., bytes not part of the output value) to be
> preserved.

This is wrong, and the fact that it's wrong is actually essential to
some usage patterns like using fgets to read files that may contain
embedded nuls.

> I see nothing in POSIX or in the BSD documentation that
> requires preservation of irrelevant bytes, either for strlcpy or for
> POSIX functions in general.  So, for example, on POSIX
> implementations where struct timespec has padding bytes, a caller
> cannot expect clock_gettime(CLOCK_REALTIME, &ts) to preserve ts's
> padding bytes, because POSIX doesn't say irrelevant bytes are
> preserved.

Padding bytes are different; they're explicitly permitted to be
altered by any stores. Moreover, in the case of clock_gettime, the
specified behavior is storing a structure. This would allow any
implementation-defined additional members in the structure to be
changed since they are also part of the structure.

> >If there's doubt we should clarify with the authors of the original.
> 
> This is not an issue that OpenBSD implementers can unilaterally
> decide now. "Ooops, there's an nonobvious strlcpy feature that we
> forgot to write down, but all implementations are required to
> support it anyway."?!? Sorry, but no. That shouldn't work for
> clock_gettime, and it shouldn't work for strlcpy either.

It's not written down because it's obvious. If all implementations
satisfy the requirement (which they do, because it's obvious, and
you'd have to go out of your way to do something malicious in order
not to satisfy it) then there is no problem with clarifying this.

Rich