From: "Edgar E. Iglesias" <edgar.iglesias@amd.com>
To: Julien Grall <julien@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>,
sstabellini@kernel.org, bertrand.marquis@arm.com,
michal.orzel@amd.com, Volodymyr_Babchuk@epam.com,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v1 1/1] arm64: Fix strrchr() matching of null terminator
Date: Tue, 19 May 2026 17:28:20 +0200 [thread overview]
Message-ID: <agyBlAsqtVEv5c38@zapote> (raw)
In-Reply-To: <3d1001c8-6761-41ba-83df-42c83a453f3e@xen.org>
On Tue, May 19, 2026 at 08:47:17AM +0100, Julien Grall wrote:
> Hi Edgar and Jan,
>
> On 19/05/2026 07:40, Jan Beulich wrote:
> > On 19.05.2026 01:43, Edgar E. Iglesias wrote:
> > > The generic Xen strrchr() implementation returns a pointer to the string
> > > terminator when searching for '\0', matching the standard C semantics.
> >>>> The ARM64 assembly version stopped as soon as it loaded the terminator
> and
> > > returned the previous match pointer instead. This made strrchr("", '\0')
> > > return NULL.
> >
> > I wonder though: Why would one pass '\0' to strrchr()? If you want to find
> > the end of a string, more efficient (at least in the general case) options
> > exist (strchr(), memchr(), strlen()).
>
> +1 I am interested to know the use-case for this change. Is this for
> compliance or real issue? If the latter, can we add some details.
>
> It might also be worth to write a selftest to avoid any regression (in
> particular if we decide to diverge from Linux).
>
> >
> > > Compare the loaded byte against the requested character before deciding
> > > whether to stop at the terminator, so the terminator itself can be returned
> > > when it is the requested character.
> >
> > Nit: "..., so a pointer to the terminator ...".
> >
> > > Fixes: 42c4eb6a83 ("xen: arm64: assembly optimised mem* and str*")
> > > Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
> >
> > Reviewed-by: Jan Beulich <jbeulich@suse.com>
> >
> > However, the function having come from Linux, imo the patch wants to go to
> > Linux (ideally first, but at the very least also).
>
> We are trying to keep the core implementation in lib the same as linux (see
> arch/arm/README.LinuxPrimitives). I would prefer if this is also first
> committed to Linux and then backported.
>
Sounds good, thanks!
next prev parent reply other threads:[~2026-05-19 15:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 23:43 [PATCH v1 0/1] arm64: Fix strrchr() matching of null terminator Edgar E. Iglesias
2026-05-18 23:43 ` [PATCH v1 1/1] " Edgar E. Iglesias
2026-05-19 6:40 ` Jan Beulich
2026-05-19 7:47 ` Julien Grall
2026-05-19 15:28 ` Edgar E. Iglesias [this message]
2026-05-19 15:24 ` Edgar E. Iglesias
2026-05-19 12:45 ` Andrew Cooper
2026-05-19 16:27 ` Edgar E. Iglesias
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=agyBlAsqtVEv5c38@zapote \
--to=edgar.iglesias@amd.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=bertrand.marquis@arm.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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.