On Tue, 2026-05-12 at 11:52 +0300, Jani Nikula wrote: > On Sun, 10 May 2026, Manuel Ebner <[email protected]> wrote: > > add strlcat and alternatives > > You'd think it's the strlcat() definition that needs a comment above it > saying it's deprecated. I don't think folks really look at > deprecated.rst.
arch/s390/lib/string.c lib/string.c and tools/include/nolibc/string.h do not mentions anything about obsolete. include/linux/fortify-string.h has /* Defined after fortified strlen() to reuse it. */ extern size_t __real_strlcat(char *p, const char *q, size_t avail) __RENAME(strlcat); /** * strlcat - Append a string to an existing string * [...] * Do not use this function. While FORTIFY_SOURCE tries to avoid * read and write overflows, this is only possible when the sizes * of @p and @q are known to the compiler. Prefer building the * string with formatting, via scnprintf(), seq_buf, or similar. should i add this to the former three files? Manuel > > BR, > Jani. > > > > > Signed-off-by: Manuel Ebner <[email protected]> > > --- > > Documentation/process/deprecated.rst | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/Documentation/process/deprecated.rst > > b/Documentation/process/deprecated.rst > > index fed56864d036..b8a65c19796c 100644 > > --- 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() > > + > > %p format specifier > > ------------------- > > Traditionally, using "%p" in format strings would lead to regular address >
