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

[David Laight <david.laight.linux@gmail.com>]

On Mon, 11 May 2026 12:07:38 -0700
Kees Cook <kees@kernel.org> wrote:

> On Mon, May 11, 2026 at 02:26:49PM +0100, David Laight wrote:
> > On Mon, 11 May 2026 13:40:55 +0200
> > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >   
> > > Hi Manuel,
> > > 
> > > On Sun, 10 May 2026 at 18:52, Manuel Ebner <manuelebner@mailbox.org> wrote:  
> > > > add strlcat and alternatives    
> > > 
> > > Thanks for your patch!
> > >   
> > > > --- a/Documentation/process/deprecated.rst
> > > > +++ b/Documentation/process/deprecated.rst
> > > > @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> > > >  though care must be given to any cases where the return value of strlcpy()
> > > >  is used, since strscpy() will return negative errno values when it truncates.
> > > >
> > > > +strlcat()
> > > > +---------
> > > > +strlcat() must re-scan the destination string from the beginning on each
> > > > +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> > > > +snprintf() and scnprintf()    
> > > 
> > > The last two not only require the caller to keep track of the offset
> > > in the buffer, but also using "%s" when storing passed strings.  
> > 
> > Which also means they are significantly slower.
> > Mind you, some code has:
> > 	strlcat(buf, "\n", SIZE);
> > 	return strlen(buf);
> > which carefully scans the string twice.
> > Since the '\0' isn't always needed (eg 'show' functions), this can be:
> > 	len = strlen(buf);
> > 	buf[len] ='\n';
> > 	return len + 1;
> > Of course, the code could often easily get the length by other means.  
> 
> I think I'd prefer to only recommend using seq_buf API. Or for sysfs,
> sysfs_emit() as seq_buf hasn't been extended there yet.

True for the docs, but rather more work when you are just trying to
get rid of strcpy() and strcat() calls.
It can be hard working out whether you can use sysfs_emit() or not.
(And I recently failed to find where the PAGE_SIZE buffer is
actually allocated; I'm sure it should just be 4k.)

-- David

> 
> -Kees
>