[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5f510b8238824aa6b3534e755f965d85@AcuMS.aculab.com>
Date: Sat, 23 Nov 2024 15:13:09 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Mateusz Guzik' <mjguzik@...il.com>, "tglx@...utronix.de"
<tglx@...utronix.de>, "bp@...en8.de" <bp@...en8.de>, "andy@...nel.org"
<andy@...nel.org>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>, Nathan Chancellor <nathan@...nel.org>
Subject: RE: [PATCH 2/2] string: retire bcmp()
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)
Powered by blists - more mailing lists