> Date: Tue, 7 Jan 2025 19:58:11 +0000 > From: nia <n...@netbsd.org> > > 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'.
