Ushering out strlcpy()

I will guess that while what you wrote is literally true, the same reasoning applies for almost everything Linux (as an operating system kernel written largely in C) does and so Linus will pronounce it stupid and decide it doesn't apply.

Mechanically, reading a byte and then writing the byte works, the data you get might have tearing, but it's still just bytes. Byte 14 of a 20 byte structure you copied might, unaccountably, be 0xF6 even though that's inconsistent with the other bytes, but it can't actually take some eldritch value outside of the 256 possible bit patterns. If you're writing a GTK+ mail app, you just shouldn't think this way, it's going to get you into trouble - but if you're writing an operating system kernel this is far from the shakiest proposition you're relying on.

Anyway, I think the race condition is a practical problem for untrusted input. If I know the kernel will read my program's buffer, find there's a NUL byte in position 814, and then cheerfully copy 814 bytes into some other structure expecting the result to be a 814 byte C-style string, then I can cause some real mischief, which might have been impossible to pull off if the kernel page-copies my entire data structure instead.