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

[Julien Grall <julien@xxxxxxx>]

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@xxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>
> 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.
Cheers,

--
Julien Grall