From: Nicholas Mc Guire <der.herr@hofr.at>
To: Ingo Molnar <mingo@kernel.org>
Cc: Nicholas Mc Guire <hofrat@osadl.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Joe Perches <joe@perches.com>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] x86, boot: add missing declaration of string functions
Date: Sat, 7 Jan 2017 09:37:22 +0000 [thread overview]
Message-ID: <20170107093722.GA19544@osadl.at> (raw)
In-Reply-To: <20170105080208.GC2098@gmail.com>
On Thu, Jan 05, 2017 at 09:02:09AM +0100, Ingo Molnar wrote:
>
> * Nicholas Mc Guire <hofrat@osadl.org> wrote:
>
> > Add the missing declarations of basic string functions to string.h to allow
> > a clean build.
> >
> > Fixes: commit 5be865661516 ("String-handling functions for the new x86 setup code.")
> > Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> > ---
> >
> > sparse issues a set of warnings about missing declarations:
> > arch/x86/purgatory/../boot/string.c:18:5: warning: symbol 'memcmp' was not declared. Should it be static?
> > arch/x86/purgatory/../boot/string.c:26:5: warning: symbol 'strcmp' was not declared. Should it be static?
> > arch/x86/purgatory/../boot/string.c:42:5: warning: symbol 'strncmp' was not declared. Should it be static?
> > arch/x86/purgatory/../boot/string.c:58:8: warning: symbol 'strnlen' was not declared. Should it be static?
> > arch/x86/purgatory/../boot/string.c:69:14: warning: symbol 'atou' was not declared. Should it be static?
> > arch/x86/purgatory/../boot/string.c:99:20: warning: symbol 'simple_strtoull' was not declared. Should it be static?
> > arch/x86/purgatory/../boot/string.c:128:8: warning: symbol 'strlen' was not declared. Should it be static?
> > arch/x86/purgatory/../boot/string.c:142:6: warning: symbol 'strstr' was not declared. Should it be static?
> >
> > This patch has one checkpatch warning about the use of simple_strtoul which
> > is obsolete. As this is an independent implementation it is not clear if
> > the changes made in simple_strtoul -> _kstrtoull might also need to be
> > applied here ?
> >
> > Patch was compile tested with: x86_64_defconfig
> >
> > Patch is against 4.9.0 (localversion-next is next-20161223)
> >
> > arch/x86/boot/string.c | 1 +
> > arch/x86/boot/string.h | 9 +++++++++
> > 2 files changed, 10 insertions(+)
> >
> > diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
> > index cc3bd58..9e240fc 100644
> > --- a/arch/x86/boot/string.c
> > +++ b/arch/x86/boot/string.c
> > @@ -14,6 +14,7 @@
> >
> > #include <linux/types.h>
> > #include "ctype.h"
> > +#include "string.h"
> >
> > int memcmp(const void *s1, const void *s2, size_t len)
> > {
> > diff --git a/arch/x86/boot/string.h b/arch/x86/boot/string.h
> > index 725e820..f6ee139 100644
> > --- a/arch/x86/boot/string.h
> > +++ b/arch/x86/boot/string.h
> > @@ -18,4 +18,13 @@ int memcmp(const void *s1, const void *s2, size_t len);
> > #define memset(d,c,l) __builtin_memset(d,c,l)
> > #define memcmp __builtin_memcmp
> >
> > +int strcmp(const char *str1, const char *str2);
> > +int strncmp(const char *cs, const char *ct, size_t count);
> > +size_t strlen(const char *s);
> > +char *strstr(const char *s1, const char *s2);
> > +size_t strnlen(const char *s, size_t maxlen);
> > +unsigned int atou(const char *s);
> > +unsigned long long simple_strtoull(const char *cp,
> > + char **endp, unsigned int base);
>
> Looks good to me, but please also mark them 'extern' to highlight the API
> declarations like the rest of the kernel does - such as kernel.h which has
> the kernel's simple_strtoull() declaration, etc.
>
> It's not required syntactically, but it's a good stylistic principle to keep
> external APIs organized.
>
thanks - added the externs and resent as V2
while this does looks consistent with other kernel header files now
checkpatch --strict will issue CHECK requests of the form:
"CHECK: extern prototypes should be avoided in .h files"
so I just wonder if this CHECK is actually consistent with coding practice ?
the argument in commit 70dc8a48357c ("checkpatch: warn when using extern with function prototypes in .h files")
being:
<snip>
Using the extern keyword on function prototypes is superfluous visual
noise so suggest removing it.
Using extern can cause unnecessary line wrapping at 80 columns and
unnecessarily long multi-line function prototypes.
<anip>
thx!
hofrat
prev parent reply other threads:[~2017-01-07 9:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-23 10:01 [PATCH RFC] x86, boot: add missing declaration of string functions Nicholas Mc Guire
2017-01-05 8:02 ` Ingo Molnar
2017-01-07 9:37 ` Nicholas Mc Guire [this message]
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=20170107093722.GA19544@osadl.at \
--to=der.herr@hofr.at \
--cc=hofrat@osadl.org \
--cc=hpa@zytor.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.