Re: Usage of strncpy in the kernel

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Tue, 7 Jan 2025 19:58:11 +0000
> From: nia <nia%NetBSD.org@localhost>
> 
> On Mon, Jan 06, 2025 at 03:23:45PM -0500, Mouse wrote:
> > No, that's not all.  It also fills the rest, if any, of the destination
> > space with more NULs.  (This can be useful to, for example, prevent
> > leaking kernel stack trash to userland.)
> 
> Unfortunately modern compilers no longer guarantee this is true.

Do you mean strlcpy or strncpy?  (Mouse was talking about strlcpy
here, and recognized a mistake in the followup.)

strlcpy has never fully initialized the destination space --
strlcpy(dst, src, n) always writes at most MIN(strlen(src) + 1, n)
bytes to dst, and it has been standardized in POSIX.1-2024 as such:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/strlcat.html

That is precisely why it is dangerous and unfit to serve as a drop-in
replacement for strncpy, as noted in the man page now:
https://man.NetBSD.org/NetBSD-10.1/strlcpy.3

For strncpy, though, if there's a modern compiler under which
strncpy(dst, src, n) fails to write exactly n bytes to dst, well, that
goes beyond even the modern entitlement of compilers to break things
(under the philosophy of UB that there must be compiler users whom the
spec binds but does not protect, and compiler authors whom the spec
protects but does not bind) and into the territory of `compiler bug'.