| Message ID | 20190313181719.87859-1-ndesaulniers@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] lib/string.c: implement a basic bcmp | expand |
On Wed, 13 Mar 2019 11:17:15 -0700 Nick Desaulniers <ndesaulniers@google.com> wrote: > +#ifndef __HAVE_ARCH_BCMP > +/** > + * bcmp - Like memcmp but a non-zero return code simply indicates a non-match. > + * @cs: One area of memory. > + * @ct: Another area of memory. > + * @count: The size of the areas. > + */ > +#undef bcmp > +int bcmp(const void *cs, const void *ct, size_t count) > +{ > + return memcmp(cs, ct, count); This is confusing where the comment says "like memcmp but .." and then just returns memcmp() unmodified. If anything, I would expect to see return !!memcmp(cs, ct, conut); or have a better comment explaining why its the same. -- Steve > +} > +EXPORT_SYMBOL(bcmp); > +#endif > +
On Wed, Mar 13, 2019 at 11:40 AM Steven Rostedt <rostedt@goodmis.org> wrote: > > On Wed, 13 Mar 2019 11:17:15 -0700 > Nick Desaulniers <ndesaulniers@google.com> wrote: > > > +#ifndef __HAVE_ARCH_BCMP > > +/** > > + * bcmp - Like memcmp but a non-zero return code simply indicates a non-match. > > + * @cs: One area of memory. > > + * @ct: Another area of memory. > > + * @count: The size of the areas. > > + */ > > +#undef bcmp > > +int bcmp(const void *cs, const void *ct, size_t count) > > +{ > > + return memcmp(cs, ct, count); > > This is confusing where the comment says "like memcmp but .." and then > just returns memcmp() unmodified. If anything, I would expect to see > > return !!memcmp(cs, ct, conut); That's more work than strictly needed. memcmp already provides the semantics of bcmp. memcmp just provides more meaning to the signedness of the return code, whereas bcmp does not. > > or have a better comment explaining why its the same. I could add something about "the signedness of the return code not providing any meaning." What would you like to see in such a comment?
On Wed, 13 Mar 2019 11:51:09 -0700 Nick Desaulniers <ndesaulniers@google.com> wrote: > > This is confusing where the comment says "like memcmp but .." and then > > just returns memcmp() unmodified. If anything, I would expect to see > > > > return !!memcmp(cs, ct, conut); > > That's more work than strictly needed. memcmp already provides the > semantics of bcmp. memcmp just provides more meaning to the > signedness of the return code, whereas bcmp does not. I figured you would say as much ;-) > > > > > or have a better comment explaining why its the same. > > I could add something about "the signedness of the return code not > providing any meaning." What would you like to see in such a comment? I think it's the wording that bothers me: + * bcmp - Like memcmp but a non-zero return code simply indicates a non-match. What about: * bcmp - Like memcmp but non-zero only means a non-match Then in the description say that bcmp() callers must not expect anything more than zero and non-zero, as different implementations only need to return non-zero for non matches. The non-zero has no other meaning like it does in memcmp(). You could add that memcmp() itself is one implementation of bcmp() but not vice versa. -- Steve
On 13/03/2019 20.01, Steven Rostedt wrote: > On Wed, 13 Mar 2019 11:51:09 -0700 > Nick Desaulniers <ndesaulniers@google.com> wrote: > >>> >>> or have a better comment explaining why its the same. >> >> I could add something about "the signedness of the return code not >> providing any meaning." What would you like to see in such a comment? > > I think it's the wording that bothers me: > > + * bcmp - Like memcmp but a non-zero return code simply indicates a non-match. > > What about: > > * bcmp - Like memcmp but non-zero only means a non-match > > Then in the description say that bcmp() callers must not expect > anything more than zero and non-zero, Yes, but let's completely avoid mentioning memcmp in the summary. bcmp - return 0 if and only if the buffers have identical contents @a: pointer to first buffer @b: pointer to second buffer @len: size of buffers The sign or magnitude of a non-zero return value has no particular meaning, and architectures may implement their own more efficient bcmp(). So while this particular implementation is a simple (tail) call to memcmp, do not rely on anything but whether the return value is zero or non-zero. Rasmus
On Wed, 13 Mar 2019 20:34:11 +0100 Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > Yes, but let's completely avoid mentioning memcmp in the summary. > > bcmp - return 0 if and only if the buffers have identical contents > @a: pointer to first buffer > @b: pointer to second buffer > @len: size of buffers > > The sign or magnitude of a non-zero return value has no particular > meaning, and architectures may implement their own more efficient > bcmp(). So while this particular implementation is a simple (tail) call > to memcmp, do not rely on anything but whether the return value is zero > or non-zero. Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Thanks! -- Steve
diff --git a/include/linux/string.h b/include/linux/string.h index 7927b875f80c..6ab0a6fa512e 100644 --- a/include/linux/string.h +++ b/include/linux/string.h @@ -150,6 +150,9 @@ extern void * memscan(void *,int,__kernel_size_t); #ifndef __HAVE_ARCH_MEMCMP extern int memcmp(const void *,const void *,__kernel_size_t); #endif +#ifndef __HAVE_ARCH_BCMP +extern int bcmp(const void *,const void *,__kernel_size_t); +#endif #ifndef __HAVE_ARCH_MEMCHR extern void * memchr(const void *,int,__kernel_size_t); #endif diff --git a/lib/string.c b/lib/string.c index 38e4ca08e757..b882692bac04 100644 --- a/lib/string.c +++ b/lib/string.c @@ -866,6 +866,21 @@ __visible int memcmp(const void *cs, const void *ct, size_t count) EXPORT_SYMBOL(memcmp); #endif +#ifndef __HAVE_ARCH_BCMP +/** + * bcmp - Like memcmp but a non-zero return code simply indicates a non-match. + * @cs: One area of memory. + * @ct: Another area of memory. + * @count: The size of the areas. + */ +#undef bcmp +int bcmp(const void *cs, const void *ct, size_t count) +{ + return memcmp(cs, ct, count); +} +EXPORT_SYMBOL(bcmp); +#endif + #ifndef __HAVE_ARCH_MEMSCAN /** * memscan - Find a character in an area of memory.
A recent optimization in Clang (r355672) lowers comparisons of the return value of memcmp against zero to comparisons of the return value of bcmp against zero. This helps some platforms that implement bcmp more efficiently than memcmp. glibc simply aliases bcmp to memcmp, but an optimized implementation is in the works. This results in linkage failures for all targets with Clang due to the undefined symbol. For now, just implement bcmp as a tailcail to memcmp to unbreak the build. This routine can be further optimized in the future. Other ideas discussed: * A weak alias was discussed, but breaks for architectures that define their own implementations of memcmp since aliases to declarations are not permitted (only definitions). Arch-specific memcmp implementations typically declare memcmp in C headers, but implement them in assembly. * -ffreestanding also is used sporadically throughout the kernel. * -fno-builtin-bcmp doesn't work when doing LTO. Link: https://bugs.llvm.org/show_bug.cgi?id=41035 Link: https://code.woboq.org/userspace/glibc/string/memcmp.c.html#bcmp Link: https://github.com/llvm/llvm-project/commit/8e16d73346f8091461319a7dfc4ddd18eedcff13 Link: https://github.com/ClangBuiltLinux/linux/issues/416 Cc: stable@vger.kernel.org Reported-by: Nathan Chancellor <natechancellor@gmail.com> Reported-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Suggested-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: James Y Knight <jyknight@google.com> Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Suggested-by: Nathan Chancellor <natechancellor@gmail.com> Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> --- Changes V1 -> V2: * Add declaration to include/linux/string.h. * Reword comment above bcmp. include/linux/string.h | 3 +++ lib/string.c | 15 +++++++++++++++ 2 files changed, 18 insertions(+)