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. -- 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 >
