Hi David, On Sat, 16 May 2026 at 18:35, David Laight <[email protected]> wrote: > On Sat, 16 May 2026 17:28:19 +0200 > Heiko Carstens <[email protected]> wrote: > > > On Thu, May 14, 2026 at 09:31:46AM -0700, Kees Cook wrote: > > > On Thu, May 14, 2026 at 06:26:53PM +0200, Manuel Ebner wrote: > > > > add strlcat and alternatives > > > > > > > > Signed-off-by: Manuel Ebner <[email protected]> > > > > --- > > > > Documentation/process/deprecated.rst | 7 +++++++ > > > > 1 file changed, 7 insertions(+) > > > > > > > > diff --git a/Documentation/process/deprecated.rst > > > > b/Documentation/process/deprecated.rst > > > > index fed56864d036..06e802f4bbfd 100644 > > > > --- a/Documentation/process/deprecated.rst > > > > +++ b/Documentation/process/deprecated.rst > > > > @@ -153,6 +153,13 @@ used, and the destinations should be marked with > > > > the `__nonstring > > > > attribute to avoid future compiler warnings. For cases still needing > > > > NUL-padding, strtomem_pad() can be used. > > > > > > > > +strlcat() > > > > +--------- > > > > +strlcat() must re-scan the destination string from the beginning on > > > > each > > > > +call (O(n^2) behavior). Alternatives are seq_buf_puts() and > > > > seq_buf_printf(). > > > > +snprintf(), scnprintf() and sysfs_emit() are possible aswell, but the > > > > adoption > > > > +of the arguments needs to be taken care off. > > > > + > > > > > > How about just: > > > > > > strlcat() must re-scan the destination string from the beginning on each > > > call (O(n^2) behavior). Use the seq_buf API or similar instead. > > > > seq_buf API for appending something to e.g. boot_command_line seems to be > > odd, > > since boot_command_line is usually "just there" (depending on architecture > > and > > boot loader). > > Indeed, but ISTR that code uses strcat() a lot of the time. > The lengths are all known, so memcpy() can be used. > > I don't really see why strlcat() should be deprecated. > Clearly there are many cases where there are better ways to do things.
https://elixir.bootlin.com/linux/v7.0.8/source/include/linux/fortify-string.h#L346 already says "Do not use this function. [...] Prefer building the * string with formatting, via scnprintf(), seq_buf, or similar.". > The only problem with strlcat() is that it returns the 'required length'. > So there are some broken uses. > - fs/nfs/flexfilelayout/flexfilelayout.c > - lib/kunit/string-stream.c (although the preceding vsnprintf() looks like > the actual bug). > There is also some very strange code in security/selinus/ima.c - but it may > be ok. > > In reality the return value of strlcat() isn't really much worse that that > of snprintf(). So we need strscat()? ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
