RE: [PATCH 2/2] string: retire bcmp()

[David Laight <David.Laight@ACULAB.COM>]

From: Mateusz Guzik
> Sent: 23 November 2024 09:47
> 
> While architectures could override it thanks to __HAVE_ARCH_BCMP, none
> of them did. Instead it was implemented as a call to memcmp().
> 
> These routines differ in the API contract: memcmp()'s result indicates
> which way the difference goes (making it usable for sorting), whereas
> bcmp()'s result merely states whether the buffers differ in any way.
> 
> This means that a dedicated optimized bcmp() is cheaper to execute than
> memcmp() for differing buffers as there is no need to compute the return
> value.
> 
> However, per the above nobody bothered to write one and it is unclear if
> it makes sense to do it.
> 
> Users which really want to compare stuff may want to handle it
> differently (like e.g., the path lookup).
> 
> As there are no users and the code is merely a wrapper around memcmp(),
> just whack it.
> 
...
> 
> -/*
> - * Clang may lower `memcmp == 0` to `bcmp == 0`.
> - */
> -int bcmp(const void *s1, const void *s2, size_t len)
> -{
> -	return memcmp(s1, s2, len);
> -}
> -

As per the comment I thought that clang would sometimes generate
calls to bcmp().

So while the two symbols could refer to the same code I don't
think it can be removed.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)