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-043aa2e16...@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
