On Mon, Aug 07, 2023 at 09:45:37AM +0200, Rasmus Villemoes wrote: > 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.
Yes, I agree it would be good to make this change. -- Tom
signature.asc
Description: PGP signature
