[PATCH v2 0/3] Doc, scripts: facilitate phaseout of strlcat

[PATCH v2 0/3] Doc, scripts: facilitate phaseout of strlcat

[Manuel Ebner]

Thanks for all the feedback. I tried to incorporate it in this version.

The goal of this series is to facilitate the transition away from strlcat()

[v2]
 add recipants
 add remarks to strlcat definition in
  lib/string.c
  tools/include/nolibc/string.h
  -> [3/3]
 

[PATCH v2 1/3] Doc: deprecated.rst: add strlcat()

[Manuel Ebner]

add strlcat and alternatives

Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
 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.
+
 strlcpy()
 ---------
 strlcpy() reads the entire source buffer first (since the return value
-- 
2.54.0

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

[Kees Cook]

On Thu, May 14, 2026 at 06:26:53PM +0200, Manuel Ebner wrote:
> add strlcat and alternatives
> 
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
>  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.


>  strlcpy()
>  ---------
>  strlcpy() reads the entire source buffer first (since the return value
> -- 
> 2.54.0
> 

-- 
Kees Cook

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

[Randy Dunlap]

On 5/14/26 9:31 AM, 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 <manuelebner@mailbox.org>
>> ---
>>  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.
> 

Yeah, that avoids the "aswell" (should be "as well").

> 
>>  strlcpy()
>>  ---------
>>  strlcpy() reads the entire source buffer first (since the return value
>> -- 
>> 2.54.0
>>
> 

-- 
~Randy

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

[Heiko Carstens]

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 <manuelebner@mailbox.org>
> > ---
> >  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.

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

[David Laight]

On Sat, 16 May 2026 17:28:19 +0200
Heiko Carstens <hca@linux.ibm.com> wrote:

> 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 <manuelebner@mailbox.org>
> > > ---
> > >  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).

Indeed, but ISTR that code uses strcat() a lot of the time.
The lengths are all known, so memcpy() can be used.

I don't really see why strlcat() should be deprecated.
Clearly there are many cases where there are better ways to do things.
The only problem with strlcat() is that it returns the 'required length'.
So there are some broken uses.
- fs/nfs/flexfilelayout/flexfilelayout.c
- lib/kunit/string-stream.c (although the preceding vsnprintf() looks like the actual bug).
There is also some very strange code in security/selinus/ima.c - but it may be ok.

In reality the return value of strlcat() isn't really much worse that that
of snprintf().

-- David

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

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

[Geert Uytterhoeven]

Hi David,

On Sat, 16 May 2026 at 18:35, David Laight <david.laight.linux@gmail.com> wrote:
> On Sat, 16 May 2026 17:28:19 +0200
> Heiko Carstens <hca@linux.ibm.com> wrote:
>
> > 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 <manuelebner@mailbox.org>
> > > > ---
> > > >  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).
>
> Indeed, but ISTR that code uses strcat() a lot of the time.
> The lengths are all known, so memcpy() can be used.
>
> I don't really see why strlcat() should be deprecated.
> Clearly there are many cases where there are better ways to do things.

https://elixir.bootlin.com/linux/v7.0.8/source/include/linux/fortify-string.h#L346
already says "Do not use this function. [...] Prefer building the
 * string with formatting, via scnprintf(), seq_buf, or similar.".

> The only problem with strlcat() is that it returns the 'required length'.
> So there are some broken uses.
> - fs/nfs/flexfilelayout/flexfilelayout.c
> - lib/kunit/string-stream.c (although the preceding vsnprintf() looks like the actual bug).
> There is also some very strange code in security/selinus/ima.c - but it may be ok.
>
> In reality the return value of strlcat() isn't really much worse that that
> of snprintf().

So we need strscat()? ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[David Laight]

On Mon, 18 May 2026 09:11:04 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Hi David,
...
> > I don't really see why strlcat() should be deprecated.
> > Clearly there are many cases where there are better ways to do things.  
> 
> https://elixir.bootlin.com/linux/v7.0.8/source/include/linux/fortify-string.h#L346
> already says "Do not use this function. [...] Prefer building the
>  * string with formatting, via scnprintf(), seq_buf, or similar.".

Trouble is that all requires a lot more rework.

I might try changing the type of the 'buffer' to sysfs_emit()
from 'char *' to 'sysfs_buf *'.
Initially the types will have to be the same, but propagating it through
will show where it can be used.
But last I looked I failed to even find the associated kmalloc().
Eventually it could be changed to a different type.

> > The only problem with strlcat() is that it returns the 'required length'.
> > So there are some broken uses.
> > - fs/nfs/flexfilelayout/flexfilelayout.c
> > - lib/kunit/string-stream.c (although the preceding vsnprintf() looks like the actual bug).
> > There is also some very strange code in security/selinus/ima.c - but it may be ok.
> >
> > In reality the return value of strlcat() isn't really much worse that that
> > of snprintf().  
> 
> So we need strscat()? ;-)

Indeed...

-- David

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

[PATCH v2 2/3] scripts: checkpatch.pl: add warning for strlcat()

[Manuel Ebner]

add a warning for strlcat()

Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
 scripts/checkpatch.pl | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0492d6afc9a1..4c1b43ebe00d 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -7085,6 +7085,12 @@ sub process {
 			     "Prefer strscpy over strlcpy - see: https://github.com/KSPP/linux/issues/89\n" . $herecurr);
 		}
 
+# strlcat uses that should be a more supported function
+		if ($line =~ /\bstrlcat\s*\(/ && !is_userspace($realfile)) {
+			WARN("STRLCAT",
+			     "Prefer a more supported function over strlcat - see: https://github.com/KSPP/linux/issues/370\n" . $herecurr);
+		}
+
 # strncpy uses that should likely be strscpy or strscpy_pad
 		if ($line =~ /\bstrncpy\s*\(/ && !is_userspace($realfile)) {
 			WARN("STRNCPY",
-- 
2.54.0

Re: [PATCH v2 2/3] scripts: checkpatch.pl: add warning for strlcat()

[Kees Cook]

On Thu, May 14, 2026 at 06:28:59PM +0200, Manuel Ebner wrote:
> add a warning for strlcat()
> 
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>

Reviewed-by: Kees Cook <kees@kernel.org>

-- 
Kees Cook

[PATCH v2 3/3] drivers: add deprecated remarks to strlcat()

[Manuel Ebner]

add kernel-doc comment to strlcat() function definitions

Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
 lib/string.c                  | 11 +++++++++++
 tools/include/nolibc/string.h | 11 +++++++++++
 2 files changed, 22 insertions(+)

diff --git a/lib/string.c b/lib/string.c
index b632c71df1a5..0a44ca5ca7e6 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -249,6 +249,17 @@ EXPORT_SYMBOL(strncat);
 #endif
 
 #ifndef __HAVE_ARCH_STRLCAT
+/**
+ * strlcat - Append a string to an existing string
+ *
+ * @dest: pointer to %NUL-terminated string to append to
+ * @src: pointer to %NUL-terminated string to append from
+ * @count: Maximum bytes available in @dest
+ *
+ * Do not use this function. Prefer building the string with
+ * formatting, via scnprintf(), seq_buf, or similar.
+ *
+ */
 size_t strlcat(char *dest, const char *src, size_t count)
 {
 	size_t dsize = strlen(dest);
diff --git a/tools/include/nolibc/string.h b/tools/include/nolibc/string.h
index 4000926f44ac..1a4b51135705 100644
--- a/tools/include/nolibc/string.h
+++ b/tools/include/nolibc/string.h
@@ -208,6 +208,17 @@ char *strndup(const char *str, size_t maxlen)
 }
 
 static __attribute__((unused))
+/**
+ * strlcat - Append a string to an existing string
+ *
+ * @dst: pointer to %NUL-terminated string to append to
+ * @src: pointer to %NUL-terminated string to append from
+ * @size: Maximum bytes available in @dst
+ *
+ * Do not use this function. Prefer building the string with
+ * formatting, via scnprintf(), seq_buf, or similar.
+ *
+ */
 size_t strlcat(char *dst, const char *src, size_t size)
 {
 	size_t len = strnlen(dst, size);
-- 
2.54.0

Re: [PATCH v2 3/3] drivers: add deprecated remarks to strlcat()

[Andy Shevchenko]

On Thu, May 14, 2026 at 7:32 PM Manuel Ebner <manuelebner@mailbox.org> wrote:
>
> add kernel-doc comment to strlcat() function definitions

Add
definitions.

...

> --- a/tools/include/nolibc/string.h
> +++ b/tools/include/nolibc/string.h

I probably missed a discussion, but nolibc is not a kernel binary,
they can choose themselves what to use, no?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 3/3] drivers: add deprecated remarks to strlcat()

[Geert Uytterhoeven]

Hi Manuel,

On Thu, 14 May 2026 at 18:32, Manuel Ebner <manuelebner@mailbox.org> wrote:
> add kernel-doc comment to strlcat() function definitions
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>

Thanks for your patch!

> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -249,6 +249,17 @@ EXPORT_SYMBOL(strncat);
>  #endif
>
>  #ifndef __HAVE_ARCH_STRLCAT
> +/**
> + * strlcat - Append a string to an existing string
> + *
> + * @dest: pointer to %NUL-terminated string to append to
> + * @src: pointer to %NUL-terminated string to append from
> + * @count: Maximum bytes available in @dest
> + *

Missing "Returns ...".

> + * Do not use this function. Prefer building the string with
> + * formatting, via scnprintf(), seq_buf, or similar.
> + *
> + */
>  size_t strlcat(char *dest, const char *src, size_t count)
>  {
>         size_t dsize = strlen(dest);

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 3/3] drivers: add deprecated remarks to strlcat()

[Andy Shevchenko]

On Fri, May 15, 2026 at 10:23 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Thu, 14 May 2026 at 18:32, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > add kernel-doc comment to strlcat() function definitions

...

> > +/**
> > + * strlcat - Append a string to an existing string
> > + *
> > + * @dest: pointer to %NUL-terminated string to append to
> > + * @src: pointer to %NUL-terminated string to append from
> > + * @count: Maximum bytes available in @dest
> > + *
>
> Missing "Returns ...".

Documentation says "Return:" as
- the section (note important colon)
- the singular (however plural is undocumented and supported)

> > + * Do not use this function. Prefer building the string with
> > + * formatting, via scnprintf(), seq_buf, or similar.
> > + *
> > + */

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 3/3] drivers: add deprecated remarks to strlcat()

[Andy Shevchenko]

On Fri, May 15, 2026 at 10:30 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Fri, May 15, 2026 at 10:23 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Thu, 14 May 2026 at 18:32, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > > add kernel-doc comment to strlcat() function definitions

...

> > > +/**
> > > + * strlcat - Append a string to an existing string
> > > + *
> > > + * @dest: pointer to %NUL-terminated string to append to
> > > + * @src: pointer to %NUL-terminated string to append from
> > > + * @count: Maximum bytes available in @dest
> > > + *
> >
> > Missing "Returns ...".
>
> Documentation says "Return:" as

I mean the kernel-doc documentation. Here the section is missed and
needs to be added, indeed.

> - the section (note important colon)
> - the singular (however plural is undocumented and supported)
>
> > > + * Do not use this function. Prefer building the string with
> > > + * formatting, via scnprintf(), seq_buf, or similar.
> > > + *
> > > + */

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 3/3] drivers: add deprecated remarks to strlcat()

[Geert Uytterhoeven]

Hi Andy,

On Fri, 15 May 2026 at 09:31, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Fri, May 15, 2026 at 10:23 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Thu, 14 May 2026 at 18:32, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > > add kernel-doc comment to strlcat() function definitions
>
> ...
>
> > > +/**
> > > + * strlcat - Append a string to an existing string
> > > + *
> > > + * @dest: pointer to %NUL-terminated string to append to
> > > + * @src: pointer to %NUL-terminated string to append from
> > > + * @count: Maximum bytes available in @dest
> > > + *
> >
> > Missing "Returns ...".
>
> Documentation says "Return:" as
> - the section (note important colon)
> - the singular (however plural is undocumented and supported)

Trailing "s" is not always plural in English ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 3/3] drivers: add deprecated remarks to strlcat()

[David Laight]

On Fri, 15 May 2026 09:32:06 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Hi Andy,
> 
> On Fri, 15 May 2026 at 09:31, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Fri, May 15, 2026 at 10:23 AM Geert Uytterhoeven
> > <geert@linux-m68k.org> wrote:  
> > > On Thu, 14 May 2026 at 18:32, Manuel Ebner <manuelebner@mailbox.org> wrote:  
> > > > add kernel-doc comment to strlcat() function definitions  
> >
> > ...
> >  
> > > > +/**
> > > > + * strlcat - Append a string to an existing string
> > > > + *
> > > > + * @dest: pointer to %NUL-terminated string to append to
> > > > + * @src: pointer to %NUL-terminated string to append from
> > > > + * @count: Maximum bytes available in @dest
> > > > + *  
> > >
> > > Missing "Returns ...".  
> >
> > Documentation says "Return:" as
> > - the section (note important colon)
> > - the singular (however plural is undocumented and supported)  
> 
> Trailing "s" is not always plural in English ;-)

It is for 'Return' :-)
Most of the exceptions are words taken directly from Latin,
where something that might be a Latin plural is used (who knows what
the Romans actually used).
It many cases the 's' plural is also valid.

-- David

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

Re: [PATCH v2 3/3] drivers: add deprecated remarks to strlcat()

[Geert Uytterhoeven]

Hi David,

On Fri, 15 May 2026 at 11:31, David Laight <david.laight.linux@gmail.com> wrote:
> On Fri, 15 May 2026 09:32:06 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Fri, 15 May 2026 at 09:31, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > > On Fri, May 15, 2026 at 10:23 AM Geert Uytterhoeven
> > > <geert@linux-m68k.org> wrote:
> > > > On Thu, 14 May 2026 at 18:32, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > > > > add kernel-doc comment to strlcat() function definitions
> > >
> > > ...
> > >
> > > > > +/**
> > > > > + * strlcat - Append a string to an existing string
> > > > > + *
> > > > > + * @dest: pointer to %NUL-terminated string to append to
> > > > > + * @src: pointer to %NUL-terminated string to append from
> > > > > + * @count: Maximum bytes available in @dest
> > > > > + *
> > > >
> > > > Missing "Returns ...".
> > >
> > > Documentation says "Return:" as
> > > - the section (note important colon)
> > > - the singular (however plural is undocumented and supported)
> >
> > Trailing "s" is not always plural in English ;-)
>
> It is for 'Return' :-)

In case "returns" is a shorthand for "return values", it indeed is ;-)
I meant a conjugation of the verb "to return".

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 0/3] Doc, scripts: facilitate phaseout of strlcat

[Manuel Ebner]

Hello

i'll ditch this series - it's just not the time yet.

Manuel

On Thu, 2026-05-14 at 18:07 +0200, Manuel Ebner wrote:
> Thanks for all the feedback. I tried to incorporate it in this version.
> 
> The goal of this series is to facilitate the transition away from strlcat()
> 
> [v2]
>  add recipants
>  add remarks to strlcat definition in
>   lib/string.c
>   tools/include/nolibc/string.h
>   -> [3/3]
>