Re: [PATCH v1 1/1] arm64: Fix strrchr() matching of null terminator

["Edgar E. Iglesias" <edgar.iglesias@amd.com>]

On Tue, May 19, 2026 at 01:45:37PM +0100, Andrew Cooper wrote:
> On 19/05/2026 12:43 am, 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.
> >
> > 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.
> >
> > Fixes: 42c4eb6a83 ("xen: arm64: assembly optimised mem* and str*")
> > Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
> > ---
> >  xen/arch/arm/arm64/lib/strrchr.S | 7 +++----
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> A couple of tangential things.
> 
> This file was inherited from Linux.  Does the same bug need fixing
> there?  What about the arm32 side?

Yes, I'll have a look at Linux. Arm32 looks fine to me.

> 
> Looking at your example, it surely wasn't actually as simple as
> strrchr("", '\0') ?  I'd expect the optimiser to be able to turn that
> into a constant and not call out to the library implementation.
> 

We ran into this while exploring a new QEMU based test framework, we had
it do some fuzzing and it tripped over this.


> Elsewhere, I've created xen/common/bitops.c to be CONFIG_SELF_TESTS for
> the bit operations including the arch-optimised variations, because
> they're subtle and easy to get wrong.  This looks like it's worth doing
> the same for the bits of libc we implement.
>

Yes, that looks like a good fit, thanks.

Cheers,
Edgar