On Mon, May 11, 2026 at 02:26:49PM +0100, David Laight wrote: > On Mon, 11 May 2026 13:40:55 +0200 > Geert Uytterhoeven <[email protected]> wrote: > > > Hi Manuel, > > > > On Sun, 10 May 2026 at 18:52, Manuel Ebner <[email protected]> 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. -Kees -- Kees Cook
