From: Alejandro Colomar <alx@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: linux-hardening@vger.kernel.org,
Krzysztof Kozlowski <krzk@kernel.org>,
"Maciej W. Rozycki" <macro@orcam.me.uk>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Andreas Schwab <schwab@linux-m68k.org>,
Andy Shevchenko <andy@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
Daniel Scally <djrscally@gmail.com>,
Danilo Krummrich <dakr@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Joe Perches <joe@perches.com>, Johan Hovold <johan@kernel.org>,
Kees Cook <kees@kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Len Brown <lenb@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linus Walleij <linusw@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Rob Herring <robh@kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Saravana Kannan <saravanak@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Tom Zanussi <zanussi@kernel.org>,
linux-acpi@vger.kernel.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org
Subject: Re: [PATCH v5 7/7] string: Implement strstarts() with strprefix()
Date: Fri, 13 Nov 2026 16:39:34 +0100 [thread overview]
Message-ID: <avcrlaWDlBVAHpnj@devuan> (raw)
In-Reply-To: <avcntwOjI2i4seyB@ashevche-desk.local>
[-- Attachment #1: Type: text/plain, Size: 4390 bytes --]
Hi Andy,
> Date: 2026-11-13 17:07:35+0200
> From: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> On Fri, Nov 13, 2026 at 03:59:46PM +0100, Alejandro Colomar wrote:
> > > On Fri, Nov 13, 2026 at 02:11:17PM +0100, Alejandro Colomar wrote:
>
> ...
>
> > > > static inline bool strstarts(const char *str, const char *prefix)
> > > > {
> > > > - return strncmp(str, prefix, strlen(prefix)) == 0;
> > > > + return strprefix(str, prefix);
> > > > }
> > >
> > > There is no sense to keep strstarts() at this point.
> >
> > I agree. Actually, it seems my guess that strprefix() would be
> > optimized out was wrong, because the kernel builds with
> > -fno-delete-null-pointer-checks and other flags that prevent this
> > optimization.
> >
> > > Can it be simply redefinition?
> >
> > I was thinking that we could just do a simple search and replace
> > s/strstarts/strends/, prepending !! in some cases if needed.
> >
> > By 'redefinition', do you mean making strstarts() return a pointer
> > instead of a bool? A problem with strstarts() is again the function
> > name: it doesn't seem to naturally fit with a function that returns a
> > pointer to the position. It also doesn't clarify whether it searches
> > for a string, or for a list of characters (like for example strspn(3)).
>
> We have str_has_*() for that?
I don't fully understand. str_has_prefix() --which is the only
str_has_*() function, BTW-- is meant to be the same as strprefix(),
except for using an offset instead of a pointer.
- strstarts():
It could be improved by returning a boolean-like pointer,
instead of a bool, but:
- We may need to fix some callers, since some of them might
need an explicit conversion with !!. It'd be risky to change
the implementation without first verifying that.
To avoid that risk, I prefer adding a new API, and
deprecating strstarts() for new code. Over time, I could
slowly migrate users from strstarts() to strprefix().
- The name isn't ideal, since "starts" doesn't specify whether
it looks for a string that starts with a given prefix, or if
it looks for a string that starts with any of the given
characters.
That is, by the name, I wouldn't be able to know whether
strstarts implements
bool strstarts(const char *s, const char *xxx)
{
return strspn(s, xxx);
}
or
bool strstarts(const char *s, const char *xxx)
{
return strprefix(s, xxx);
}
- strends():
Same as with strstarts() but from the end.
- str_has_prefix():
It was an attempt at strprefix(), but with a problematic
approach. It's frozen because of trace code.
- strprefix()/strsuffix():
I'd add them to slowly replace strstarts()/strends().
>
> > I prefer replacing strstarts()/strends() with strprefix()/strsuffix().
> >
> > But if you prefer changing strstarts() to return a pointer, I'm also
> > okay-ish with it. It's not a perfect name, but I can live with it.
> >
> > > However, after looking at the uses in the kernel, I prefer
> > > to see the strprefix() be not implemented at all, just optimization against
> > > strstarts()/strends() if required can be performed.
> >
> > I don't understand this last sentence.
>
> It's basically repeats the idea of having only one pair out of two.
Ok.
> With this series will be
>
> str_has_previx()
> strstarts()
> strends()
> strprefix()
> // potentially strsuffix()
Yes. I'd like to replace strstarts()/strends() with
strprefix()/strsuffix(), but prefer to do that slowly, to avoid
introducing bugs due to missing explicit conversions to bool.
Should I add notes that the strstarts()/strends() APIs are deprecated?
> To me seems too many for the similar task. I understand that trace user is
> special one, but does it use strstarts()/strends()?
I didn't find any uses:
$ git ls-files | grep kernel/trace/ | xargs grep strstarts
$ git ls-files | grep kernel/trace/ | xargs grep strends
> Despite on naming I think we just good to have only str_has*() and one of
> strprefix()/strsuffix(), strstarts()/strends().
In the long term, I agree. But I think the transition should be
careful. What do you think?
Cheers,
Alex
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-11-13 15:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 13:10 [PATCH v5 0/7] Add strprefix() and fix a bug with it Alejandro Colomar
2026-11-13 13:10 ` [PATCH v5 1/7] string: Add strprefix(), and deprecate str_has_prefix() Alejandro Colomar
2026-11-13 14:33 ` Andy Shevchenko
2026-11-13 14:34 ` Andy Shevchenko
2026-11-13 14:40 ` Alejandro Colomar
2026-11-13 14:47 ` Andy Shevchenko
2026-11-13 13:10 ` [PATCH v5 2/7] string: Warn if the prefix is the empty string Alejandro Colomar
2026-11-13 13:26 ` sashiko-bot
2026-11-13 13:48 ` Alejandro Colomar
2026-11-13 14:25 ` Andy Shevchenko
2026-11-13 14:32 ` Alejandro Colomar
2026-11-13 13:10 ` [PATCH v5 3/7] device property: Fix fwnode_name_eq() for empty node names Alejandro Colomar
2026-11-13 13:10 ` [PATCH v5 4/7] stddef: Add const_cast() Alejandro Colomar
2026-11-13 13:11 ` [PATCH v5 5/7] string: Add [C]QChar_of() and QVoid_of() Alejandro Colomar
2026-11-13 13:11 ` [PATCH v5 6/7] string: Make strprefix() const-qualifier-generic Alejandro Colomar
2026-11-13 13:11 ` [PATCH v5 7/7] string: Implement strstarts() with strprefix() Alejandro Colomar
2026-11-13 13:20 ` sashiko-bot
2026-11-13 13:36 ` Alejandro Colomar
2026-11-13 14:44 ` Andy Shevchenko
2026-11-13 14:59 ` Alejandro Colomar
2026-11-13 15:07 ` Andy Shevchenko
2026-11-13 15:39 ` Alejandro Colomar [this message]
2026-11-13 16:05 ` Andy Shevchenko
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=avcrlaWDlBVAHpnj@devuan \
--to=alx@kernel.org \
--cc=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=brgl@kernel.org \
--cc=dakr@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=djrscally@gmail.com \
--cc=driver-core@lists.linux.dev \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=joe@perches.com \
--cc=johan@kernel.org \
--cc=kees@kernel.org \
--cc=krzk@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=lenb@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@orcam.me.uk \
--cc=namhyung@kernel.org \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=rostedt@goodmis.org \
--cc=sakari.ailus@linux.intel.com \
--cc=saravanak@kernel.org \
--cc=schwab@linux-m68k.org \
--cc=torvalds@linux-foundation.org \
--cc=zanussi@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.