public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Rodrigo Campos <rodrigo@sdfg.com.ar>
Cc: "Thomas Weißschuh" <linux@weissschuh.net>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] tools/nolibc: Fix strlcat() return code and size usage
Date: Sun, 11 Feb 2024 11:48:17 +0100	[thread overview]
Message-ID: <20240211104817.GA19364@1wt.eu> (raw)
In-Reply-To: <20240129141516.198636-3-rodrigo@sdfg.com.ar>

Hi Rodrigo,

first, thanks for the series!

On Mon, Jan 29, 2024 at 03:15:14PM +0100, Rodrigo Campos wrote:
> The return code should always be strlen(src) + strlen(dst), but dst is
> considered shorter if size is less than strlen(dst).
> 
> While we are there, make sure to copy at most size-1 bytes and
> null-terminate the dst buffer.
> 
> Signed-off-by: Rodrigo Campos <rodrigo@sdfg.com.ar>
> ---
>  tools/include/nolibc/string.h | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/include/nolibc/string.h b/tools/include/nolibc/string.h
> index ed15c22b1b2a..b2149e1342a8 100644
> --- a/tools/include/nolibc/string.h
> +++ b/tools/include/nolibc/string.h
> @@ -187,23 +187,23 @@ char *strndup(const char *str, size_t maxlen)
>  static __attribute__((unused))
>  size_t strlcat(char *dst, const char *src, size_t size)
>  {
> -	size_t len;
>  	char c;
> +	size_t len = strlen(dst);
> +	size_t ret = strlen(src) + (size < len? size: len);

From what I'm reading in the man page, ret should *always* be the sum
of the two string lengths. I guess it helps for reallocation. It's even
explicitly mentioned:

  "While this may seem somewhat confusing, it was done to make truncation
   detection simple."

Above ret will be bound to the existing size so a realloc wouldn't work.
Thus I think the correct solution is:

	size_t ret = strlen(src) + len;

> -	for (len = 0; dst[len];	len++)
> -		;
> -
> -	for (;;) {
> +	for (;len < size;) {
>  		c = *src;
> -		if (len < size)
> +		if (len < size - 1)
>  			dst[len] = c;
> +		if (len == size - 1)
> +			dst[len] = '\0';
>  		if (!c)
>  			break;
>  		len++;
>  		src++;
>  	}
>  
> -	return len;
> +	return ret;
>  }

The test inside the loop is going to make this not very efficient. Same
for the fact that we're measuring the length of src twice (once via
strlen, a second time through the loop). I've just had a look and it
compiles to 77 bytes at -Os. A simpler variant would consist in trying
to copy what fits in <size> and once reached, go on just for trailing
zero and the size measurement:

size_t strlcat(char *dst, const char *src, size_t size)
{
        size_t len = strlen(dst);

        while (len < size) {
                if (!(dst[len] = *src))
                        return len;
                len++;
                src++;
        }

        /* end of src not found before size */

        if (size)
                dst[size - 1] = '\0';

        while (*src++)
                len++;

        return len;
}

For me it's 58 bytes, or 19 less / 25% smaller, and at first glance it
should do the right thing as well.

What do you think ?

Thanks!
Willy

  reply	other threads:[~2024-02-11 10:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-29 14:15 [PATCH 0/4] tools/nolibc: Misc fixes for strlcpy() and strlcat() Rodrigo Campos
2024-01-29 14:15 ` [PATCH 1/4] tools/nolibc/string: export strlen() Rodrigo Campos
2024-01-29 14:15 ` [PATCH 2/4] tools/nolibc: Fix strlcat() return code and size usage Rodrigo Campos
2024-02-11 10:48   ` Willy Tarreau [this message]
2024-02-12 23:16     ` Rodrigo Campos
2024-02-13  5:27       ` Rodrigo Campos
2024-02-13  6:20       ` Rodrigo Campos
2024-02-13  7:02       ` Willy Tarreau
2024-02-14 15:19         ` Rodrigo Campos
2024-02-13  6:04     ` Rodrigo Campos
2024-02-14 15:34     ` Rodrigo Campos
2024-02-14 22:03       ` Rodrigo Campos
2024-02-14 22:47         ` Rodrigo Campos
2024-02-18 10:22         ` Willy Tarreau
2024-02-18 10:20       ` Willy Tarreau
2024-02-18 19:33         ` Rodrigo Campos
2024-01-29 14:15 ` [PATCH 3/4] tools/nolibc: Fix strlcpy() " Rodrigo Campos
2024-02-11 11:08   ` Willy Tarreau
2024-02-11 11:14     ` Willy Tarreau
2024-02-14 15:50     ` Rodrigo Campos
2024-02-14 15:55       ` Willy Tarreau
2024-01-29 14:15 ` [PATCH 4/4] selftests/nolibc: Add tests for strlcat() and strlcpy() Rodrigo Campos
2024-02-11 11:09   ` Willy Tarreau
2024-02-14 15:52   ` Rodrigo Campos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240211104817.GA19364@1wt.eu \
    --to=w@1wt.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=rodrigo@sdfg.com.ar \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox