From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: David Laight <David.Laight@ACULAB.COM>,
'Nick Desaulniers' <ndesaulniers@google.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Cc: "clang-built-linux@googlegroups.com"
<clang-built-linux@googlegroups.com>,
"linux-kbuild@vger.kernel.org" <linux-kbuild@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
Nathan Chancellor <natechancellor@gmail.com>,
Adhemerval Zanella <adhemerval.zanella@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
James Y Knight <jyknight@google.com>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Steven Rostedt <rostedt@goodmis.org>,
Namhyung Kim <namhyung@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4] lib/string.c: implement a basic bcmp
Date: Thu, 14 Mar 2019 12:07:22 +0100 [thread overview]
Message-ID: <2899ec10-2ab6-d3a3-37f5-d52395c03a8e@rasmusvillemoes.dk> (raw)
In-Reply-To: <953400721b6c4b869b9278c44e0aa796@AcuMS.aculab.com>
On 14/03/2019 10.57, David Laight wrote:
> From: Nick Desaulniers
>> Sent: 13 March 2019 21:14
> ...
>> 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
>
> Shouldn't that prototype always be present?
Yes and no. The problem is that asm/string.h may decide to implement
bcmp (or memcpy, memset, strcpy, ...) as a macro, which would break
rather badly when used to declare the function. And we can't undef the
macro temporarily. So I think the convention is that asm/string.h
provides the prototype before it #defines the macro, see e.g.
arch/x86/include/asm/string_32.h which has a #define of memcpy.
There is a fix for the "may be defined as a function-like macro", which is
extern int (bcmp)(const void *,const void *,__kernel_size_t);
I'd like to see that used rather than the ad hoc convention, but it is
of course somewhat unconventional C.
Rasmus
next prev parent reply other threads:[~2019-03-14 11:07 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-12 21:52 [PATCH] Makefile: Add '-fno-builtin-bcmp' to CLANG_FLAGS Nathan Chancellor
2019-03-12 22:55 ` Nick Desaulniers
2019-03-13 8:13 ` Rasmus Villemoes
2019-03-13 10:58 ` Masahiro Yamada
2019-03-13 13:44 ` Nathan Chancellor
2019-03-13 13:48 ` Arnd Bergmann
2019-03-13 15:32 ` Nathan Chancellor
2019-03-13 17:21 ` Nick Desaulniers
2019-03-13 17:27 ` Nick Desaulniers
2019-03-13 18:02 ` [PATCH] lib/string.c: implement a basic bcmp Nick Desaulniers
2019-03-13 18:11 ` Nick Desaulniers
2019-03-13 18:17 ` [PATCH v2] " Nick Desaulniers
2019-03-13 18:40 ` Steven Rostedt
2019-03-13 18:51 ` Nick Desaulniers
2019-03-13 19:01 ` Steven Rostedt
2019-03-13 19:34 ` Rasmus Villemoes
2019-03-13 20:12 ` Steven Rostedt
2019-03-13 20:37 ` [PATCH v3] " Nick Desaulniers
2019-03-13 21:03 ` Steven Rostedt
2019-03-13 21:13 ` [PATCH v4] " Nick Desaulniers
2019-03-14 3:15 ` Nathan Chancellor
2019-03-14 5:00 ` Masahiro Yamada
2019-03-14 8:33 ` Andy Shevchenko
2019-03-14 9:57 ` David Laight
2019-03-14 11:07 ` Rasmus Villemoes [this message]
2019-03-21 2:11 ` Andrew Morton
2019-03-21 17:02 ` Nick Desaulniers
2019-03-21 17:20 ` Nick Desaulniers
2019-03-21 21:05 ` Andrew Morton
2019-03-22 7:17 ` Rasmus Villemoes
2019-03-22 7:43 ` Sedat Dilek
2019-03-13 19:38 ` [PATCH] Makefile: Add '-fno-builtin-bcmp' to CLANG_FLAGS Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2899ec10-2ab6-d3a3-37f5-d52395c03a8e@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--cc=David.Laight@ACULAB.COM \
--cc=adhemerval.zanella@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=clang-built-linux@googlegroups.com \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jyknight@google.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung@kernel.org \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=rostedt@goodmis.org \
--cc=stable@vger.kernel.org \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).