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

[David Laight]

On Mon, 11 May 2026 13:40:55 +0200
Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:

> Hi Manuel,
> 
> On Sun, 10 May 2026 at 18:52, Manuel Ebner <manuelebner@xxxxxxxxxxx> 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.

-- David

> 
> I hope we won't see mindless conversions lacking the "%s",
> introducing new security issues:
> 
>     -strlcat(buf, s, size);
>     +scnprintf(buf + off, size - off, s);
> 
> > +
> >  %p format specifier
> >  -------------------
> >  Traditionally, using "%p" in format strings would lead to regular address  
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
>