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

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

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@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.
>

Sounds good, thanks!