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). So if I would remove strlcat() from appending something to boot_command_line I would end up open-coding strlcat(), including the chance for the usual off-by-one bugs. Looks like this would be true for nearly all architectures. Is performance really the only reason to deprecate strlcat()? This seems to be a bit questionable to me.
