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, 18 Feb 2024 11:20:03 +0100	[thread overview]
Message-ID: <20240218102003.GA32375@1wt.eu> (raw)
In-Reply-To: <10b97cd3-5690-40b2-aa8e-3fea5dd4275f@sdfg.com.ar>

Hi Rodrigo,

On Wed, Feb 14, 2024 at 12:34:46PM -0300, Rodrigo Campos wrote:
> Here are two versions that are significantly shorter than the 101 bytes,
> that pass the tests (I added more to account for the src vs dst mismatch
> that was easy to pass tests when both buffers have the same size as they did
> before).
> 
> size_t strlcat_rata(char *dst, const char *src, size_t size)
> {
>         const char *orig_src = src;
>         size_t len = 0;
>         for (;len < size; len++) {
>                 if (dst[len] == '\0')
>                         break;
>         }
> 
>         /* Let's copy len < n < size-1 times from src.
>          * size is unsigned, so instead of size-1, that can wrap around,
>          * let's use len + 1 */
>         while (len + 1 < size) {
>                 dst[len] = *src;
>                 if (*src == '\0')
>                         break;
>                 len++;
>                 src++;
>         }
> 
>         if (src != orig_src)
>                 dst[len] = '\0';
> 
>         while (*src++)
>                 len++;
> 
>         return len;
> }
> 
> This one compiles to 81 bytes here using gcc 13.2.0 and to 83 using gcc
> 9.5.0. Compared to the one posted in the patchset, it is significantly
> smaller.

OK this looks good to me. I think your test on src != orig_src is not
trivial and that testing instead if (len < size) would be better, and
possibly even shorter.

> One based in the version you posted (uses strlen(dst) instead), is this one:
> 
> size_t strlcat_willy_fixed(char *dst, const char *src, size_t size)
> {
>         const char *orig_src = src;
>         size_t len = strlen(dst);
>         if (size < len)
>                 len = size;
> 
>         for (;len + 1 < size; len++, src++) {
>                 dst[len] = *src;
>                 if (*src == '\0')
>                         break;
>         }
> 
>         if (orig_src != src)
>                 dst[len] = '\0';
> 
>         while (*src++)
>                 len++;
> 
>         return len;
> }
> 
> 
> Note the "if size < len, then len=size", I couldn't get rid of it because we
> need to account for the smaller size of dst if we don't get passed it for
> the return code.

Please no, again as I mentioned earlier, it's wrong to use strlen(dst) in
this case: the only situation where we'd accept size < len is if dst is
already not zero-terminated, which means that strlen() cannot be used, or
you'd need strnlen() for that, I'm just seeing that we have it, I thought
we didn't.

> This one is 90 bytes here.

See the point I was making? Sometimes the amount of fat added around a
function call is important compared to just an increment and a comparison.
Of course that's not always true but that's one such example.

> What do you think? Can you make them shorter?

I don't want to enter that activity again this week-end ;-)  It's sufficient
here.

> If you like one of these, I can repost with the improved tests too.

Yeah please check the few points above for your version, make sure to
clean it up according to the kernel's coding style (empty line after
variable declaration, */ on the next line for the multi-line comment
etc) and that's fine.

Thanks,
Willy

  parent reply	other threads:[~2024-02-18 10:20 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
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 [this message]
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=20240218102003.GA32375@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