Re: [PATCH 1/2] Revert "lib: string: Fix strlcpy return value", fix callers

[Rasmus Villemoes <rasmus.villemoes@prevas.dk>]

On 14/07/2023 13.24, Matthias Schiffer wrote:
> Both the Linux kernel and libbsd agree that strlcpy() should always
> return strlen(src) and not include the NUL termination. The incorrect
> U-Boot implementation makes it impossible to check the return value for
> truncation, and breaks code written with the usual implementation in
> mind (for example, fdtdec_add_reserved_memory() was subtly broken).

So while we're fixing non-standard string function behaviour, can we
_please_ finally fix strncpy() so it follows C/POSIX?

https://lore.kernel.org/u-boot/52bc92d4-8651-48df-3577-043aa2e16722@prevas.dk/

Note in particular the very last paragraph.

To rephrase and give a concrete example, what I'm worried about is us
importing some file system code that (correctly) uses strncpy() to fully
initialize some memory buffer, then writes that out to disk - but with
our crippled strncpy(), the result is potential garbage on-disk, which
both our own read implementation (which is likely also just copied) and
the kernel's may subsequently choke on.

Correctness first, please. If there are any performance problems, those
should be identified individually and perhaps rewritten to not use
strncpy() after verifying that not zeroing the tail is ok for that call
site.

Rasmus