[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=MecMJDNA=ry6YnyFxq_EeTDG6hfx2+wg+OTPBfdzXKFeA@mail.gmail.com>
Date: Tue, 18 Nov 2025 11:14:22 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Kees Cook <kees@...nel.org>, Andy Shevchenko <andy@...nel.org>,
Linus Walleij <linus.walleij@...aro.org>, linux-hardening@...r.kernel.org,
linux-kernel@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [PATCH 0/2] string: strends() follow-ups
On Tue, Nov 18, 2025 at 11:09 AM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
>
> On Tue, Nov 18, 2025 at 12:04 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
>
> > A couple follow-up changes to the new strends() string helper. This
> > needs to go through the GPIO tree as this is where the strends()
> > currently is.
>
> It appears that due to some local issue my messages from the last 8
> days disappeared and seemed to never be delivered. I tried to review
> your v4 again and I have comments on this and patch 3. For the
> strends() I proposed to get rid of strlen() calls by
>
> char *p;
>
> p = strrchr(str, suffix[0[);
> if (!p)
> return false;
>
> return strcmp(p, suffix) == 0;
>
IMO that's a bit less readable. Unless you benchmark it and show it's
faster than the current version, I'd say: let's keep the current
implementation.
Bart
Powered by blists - more mailing lists