From: Alejandro Colomar <alx+linux-hardening@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: alx@kernel.org, andy@kernel.org,
bartosz.golaszewski@oss.qualcomm.com, brgl@kernel.org,
dakr@kernel.org, devicetree@vger.kernel.org, djrscally@gmail.com,
driver-core@lists.linux.dev, gregkh@linuxfoundation.org,
heikki.krogerus@linux.intel.com, hverkuil-cisco@xs4all.nl,
joe@perches.com, johan@kernel.org, kees@kernel.org,
laurent.pinchart@ideasonboard.com, lenb@kernel.org,
linusw@kernel.org, linux-acpi@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hardening@vger.kernel.org,
linux-kernel@vger.kernel.org, namhyung@kernel.org,
rafael@kernel.org, robh@kernel.org, rostedt@goodmis.org,
sakari.ailus@linux.intel.com, saravanak@kernel.org,
schwab@linux-m68k.org, torvalds@linux-foundation.org,
zanussi@kernel.org
Subject: Re: [PATCH v2 1/2] string: Add strprefix(), and deprecate str_has_prefix()
Date: Thu, 5 Nov 2026 14:12:25 +0100 [thread overview]
Message-ID: <aux8LYQkGSNjCGHv@devuan> (raw)
In-Reply-To: <20261105125154.83478-1-geert@linux-m68k.org>
[-- Attachment #1: Type: text/plain, Size: 4792 bytes --]
Hi Geert,
> Date: 2026-11-05 13:51:54+0100
> From: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Hi Alejandro,
>
> On Thu, 5 Nov 2026 13:46:29, Alejandro Colomar wrote:
> > As Bartosz reported, str_has_prefix() has a bug: it can't differentiate
> > between an empty prefix matching an empty string from a non-matching
> > prefix. This is a fundamental design flaw in this API, and not
> > something that can be fixed.
> >
> > As always, this is a consequence of choosing sizes instead of pointers.
> > Sizes are often the wrong choice. In this specific case, pointers are
> > more capable of differentiating these cases, as NULL is a special
> > sentinel value that doesn't need to overload a valid value.
> >
> > Let's implement strprefix(), a function that returns a pointer
> > right after the prefix if found, and a null pointer if not found.
> >
> > We'll slowly migrate existing code from str_has_prefix() to strprefix().
> >
> > Reported-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > Cc: Andy Shevchenko <andy@kernel.org>
> > Signed-off-by: Alejandro Colomar <alx@kernel.org>
>
> Thanks for your patch!
:-)
> > --- a/include/linux/string.h
> > +++ b/include/linux/string.h
> > @@ -545,16 +545,33 @@ void memcpy_and_pad(void *dest, size_t dest_len, const void *src, size_t count,
> > sizeof(*(obj)) - offsetof(typeof(*(obj)), member)); \
> > })
> >
> > +/**
> > + * strprefix - string prefix
>
> Naive me assumes this function must return the prefix of the string,
> so IMO is it named badly.
To return the prefix, it'd have to return the second parameter, but the
called already has that, so I expect users would be smart enough to not
expect that.
One could expect that it maybe returns the prefix within the string, but
that would mean returning the string itself, since the prefix must
necessarily start in the first byte. So, I also expect users to be
smart enough to not expect that.
A plausible name to avoid the pathological interpretations of the name
could be strafterprefix(), but I tend to dislike the unnecessary 'after'
in the name, perhaps because I think the interpretations above are
pathologically wrong.
Do you think strafterprefix() would be better? Do you have any other
suggestions?
I would prefer keeping the name strprefix(), and perhaps improving
documentation.
> > + * @s: The string to be tested
> > + * @prefix: The string to see if @s starts with
> > + *
> > + * Returns:
> > + * * @s+strlen(@prefix) if @s starts with @prefix
> > + * * NULL if @s does not start with @prefix
> > + */
> > +static __always_inline char *strprefix(const char *s, const char *prefix)
>
> This returns a non-const substring of the original const parameter, thus
> allowing the caller to modify the original even when it is const.
>
> While this is not uncommon behavior for existing standard string
> helpers, I think it would be good to make new functions safer, by not
> allowing to drop constness. Using _Generic() can be used to support
> both const and non-const strings in a safe way.
Agree. That's in fact what we do in shadow-utils. I didn't do it here,
because I didn't know if that kind of magic would be appreciated here.
Here's what we do in shadow-utils:
#define strprefix(s, prefix) \
( \
const_cast(CQChar_of(s) *, strprefix_(s, prefix)) \
)
#define const_cast(T, p) _Generic(p, const T: (T) (p), default: (p))
#define CQChar_of(s) QChar_of(const, s)
#define QChar_of(Q, s) typeof \
( \
_Generic((QVoid_of(s) *){0}, \
Q void *: (Q char){0}, \
void *: (char){0} \
) \
)
#define QVoid_of(p) typeof((QVoidptrof_(p)){0}[0])
#define QVoidptrof_(p) typeof(1?(p):(void*){0})
const char *
strprefix_(const char *s, const char *prefix)
{
if (strncmp(s, prefix, strlen(prefix)) != 0)
return NULL;
return s + strlen(prefix);
}
I could do the same here. Do we want a const_cast() macro? Or do we
want an open-coded cast? We use const_cast() in shadow-utils to prevent
accidents in casts that may do very bad stuff. const_cast() makes sure
we only drop (or add) const at most.
Also, do we want to add the old-style strprefix() now and improve the
const-correctness in a separate patch set? Or do we want to do all at
once? I don't mind either way.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-11-05 13:12 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 11:12 [PATCH v1 0/2] Add strprefix() and fix a bug with it Alejandro Colomar
2026-11-05 11:13 ` [PATCH v1 1/2] string: Add strprefix(), and deprecate str_has_prefix() Alejandro Colomar
2026-11-05 11:27 ` Andy Shevchenko
2026-11-05 12:28 ` Alejandro Colomar
2026-11-05 16:14 ` Steven Rostedt
2026-11-05 16:33 ` Alejandro Colomar
2026-11-05 16:50 ` Steven Rostedt
2026-11-05 17:46 ` Alejandro Colomar
2026-11-05 18:08 ` Andy Shevchenko
2026-11-05 18:12 ` Andy Shevchenko
2026-11-05 11:13 ` [PATCH v1 2/2] device property: Fix fwnode_name_eq() for empty node names Alejandro Colomar
2026-11-05 11:24 ` [PATCH v1 0/2] Add strprefix() and fix a bug with it Andy Shevchenko
2026-11-05 11:38 ` Alejandro Colomar
2026-11-05 11:59 ` Andy Shevchenko
2026-11-05 12:30 ` Bartosz Golaszewski
2026-11-05 12:49 ` Alejandro Colomar
2026-11-05 12:46 ` [PATCH v2 " Alejandro Colomar
2026-11-05 12:46 ` [PATCH v2 1/2] string: Add strprefix(), and deprecate str_has_prefix() Alejandro Colomar
2026-11-05 12:51 ` Geert Uytterhoeven
2026-11-05 13:12 ` Alejandro Colomar [this message]
2026-11-05 12:46 ` [PATCH v2 2/2] device property: Fix fwnode_name_eq() for empty node names Alejandro Colomar
2026-11-05 14:01 ` [PATCH v2 0/2] Add strprefix() and fix a bug with it Bartosz Golaszewski
2026-11-05 14:16 ` Alejandro Colomar
2026-11-05 14:42 ` Andy Shevchenko
2026-11-05 15:06 ` Alejandro Colomar
2026-11-05 15:00 ` Bartosz Golaszewski
2026-11-05 15:14 ` Alejandro Colomar
2026-11-05 15:21 ` Krzysztof Kozlowski
2026-11-05 16:27 ` Steven Rostedt
2026-11-05 16:30 ` Krzysztof Kozlowski
2026-11-05 16:42 ` Alejandro Colomar
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=aux8LYQkGSNjCGHv@devuan \
--to=alx+linux-hardening@kernel.org \
--cc=alx@kernel.org \
--cc=andy@kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--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=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=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 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®