From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: mingo@kernel.org, jpoimboe@redhat.com, keescook@chromium.org,
akpm@linux-foundation.org, tglx@linutronix.de,
geert@linux-m68k.org, gregkh@linuxfoundation.org,
thomas.lendacky@amd.com, rientjes@google.com,
will.deacon@arm.com, linux-kernel@vger.kernel.org
Subject: [PATCH] Support the nonstring variable attribute (gcc >= 8)
Date: Sat, 17 Feb 2018 20:10:35 +0100 [thread overview]
Message-ID: <20180217191035.gol4woxsgzpo4bfq@gmail.com> (raw)
>From the GCC manual:
The nonstring variable attribute specifies that an object or member
declaration with type array of char or pointer to char is intended to
store character arrays that do not necessarily contain a terminating NUL
character. This is useful in detecting uses of such arrays or pointers
with functions that expect NUL-terminated strings, and to avoid warnings
when such an array or pointer is used as an argument to a bounded string
manipulation function such as strncpy.
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html
Some reports are already coming to the LKML regarding these
warnings. When they are false positives, we can use __nonstring to let
gcc know a NUL character is not required; like in this case:
https://lkml.org/lkml/2018/1/16/135
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: David Rientjes <rientjes@google.com>
---
Another option is using -Wno-stringop-truncation, but it remains to be
seen how useful the new warning will be. We can try to keep it for the
moment until the real bugs and false positives are dealt with and see if
it is worth it.
At least in the reported case at drivers/auxdisplay, using __nonstring
is enough and it can actually replace a comment that was there about the
non-stringness of the char arrays that gcc complained about.
See https://godbolt.org/g/dydPah to play with the warning in this case.
include/linux/compiler-gcc.h | 14 ++++++++++++++
include/linux/compiler_types.h | 4 ++++
2 files changed, 18 insertions(+)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 73bc63e0a1c4..6a9784c0c7f3 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -317,6 +317,20 @@
#define __designated_init __attribute__((designated_init))
#endif
+#if GCC_VERSION >= 80000
+/*
+ * The nonstring variable attribute specifies that an object or member
+ * declaration with type array of char or pointer to char is intended
+ * to store character arrays that do not necessarily contain a terminating
+ * NUL character. This is useful in detecting uses of such arrays or pointers
+ * with functions that expect NUL-terminated strings, and to avoid warnings
+ * when such an array or pointer is used as an argument to a bounded string
+ * manipulation function such as strncpy.
+ * https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html
+ */
+#define __nonstring __attribute__((nonstring))
+#endif
+
#endif /* gcc version >= 40000 specific checks */
#if !defined(__noclone)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 6b79a9bba9a7..654dd3114052 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -271,4 +271,8 @@ struct ftrace_likely_data {
# define __native_word(t) (sizeof(t) == sizeof(char) || sizeof(t) == sizeof(short) || sizeof(t) == sizeof(int) || sizeof(t) == sizeof(long))
#endif
+#ifndef __nonstring
+# define __nonstring
+#endif
+
#endif /* __LINUX_COMPILER_TYPES_H */
--
2.14.1
next reply other threads:[~2018-02-17 19:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-17 19:10 Miguel Ojeda [this message]
2018-02-18 23:20 ` [PATCH] Support the nonstring variable attribute (gcc >= 8) David Rientjes
2018-02-19 0:01 ` Miguel Ojeda
2018-03-01 9:57 ` Arnd Bergmann
2018-03-02 17:36 ` Miguel Ojeda
2018-03-05 19:05 ` Martin Sebor
2018-03-07 12:20 ` Miguel Ojeda
2018-03-13 15:41 ` Martin Sebor
2018-03-13 15:57 ` Miguel Ojeda
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=20180217191035.gol4woxsgzpo4bfq@gmail.com \
--to=miguel.ojeda.sandonis@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rientjes@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=will.deacon@arm.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).