mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rodrigo Campos <rodrigo@sdfg.com.ar>
To: Willy Tarreau <w@1wt.eu>
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: Wed, 14 Feb 2024 12:34:46 -0300	[thread overview]
Message-ID: <10b97cd3-5690-40b2-aa8e-3fea5dd4275f@sdfg.com.ar> (raw)
In-Reply-To: <20240211104817.GA19364@1wt.eu>

On 2/11/24 11:48, Willy Tarreau wrote:
> On Mon, Jan 29, 2024 at 03:15:14PM +0100, Rodrigo Campos wrote:
> 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

The sizes here don't match that, even using gcc 9.5.0 from debian sid 
(your example in the other email was calling gcc 9.5).

Here I see bigger sizes, even using the same line you share to compile.

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

I see 69 bytes for that func (nm --size says 45, that is in hex).
The function I posted in the patchset I see it as 101 bytes, so that is 
here is 32 bytes less here.

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.


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.

This one is 90 bytes here.


What do you think? Can you make them shorter?

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

  parent reply	other threads:[~2024-02-14 15:34 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 [this message]
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=10b97cd3-5690-40b2-aa8e-3fea5dd4275f@sdfg.com.ar \
    --to=rodrigo@sdfg.com.ar \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=w@1wt.eu \
    /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

all inboxes | Powered by JetHome®