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
next prev parent 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