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

[Tom Rini]

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-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.

Yes, I agree it would be good to make this change.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230809/097bb3ed/attachment.sig>