Re: [PATCH v2 1/3] Doc: deprecated.rst: add strlcat()

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