From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: linux-sparse@vger.kernel.org
Cc: Dibyendu Majumdar <mobile@majumdar.org.uk>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Subject: [PATCH] fix expansion of constant bitfield dereference
Date: Mon, 21 Aug 2017 00:16:02 +0200 [thread overview]
Message-ID: <20170820221602.27852-1-luc.vanoostenryck@gmail.com> (raw)
During the expansion of a dereference, it's if the initializer
which corrrespond to the offset we're interested is a constant.
In which case this dereference can be avoided and the value
given in the initializer can be used instead.
However, it's not enough to check for the offset since for bitfields
several are placed at the same offset.
Currently, the first initializer matching the offset is selected.
Fix this by refusing such expansion if the constant value correspond
to a bitfield.
Reported-by: Dibyendu Majumdar <mobile@majumdar.org.uk>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
---
expand.c | 2 ++
validation/bitfield-expand-deref.c | 27 +++++++++++++++++++++++++++
2 files changed, 29 insertions(+)
create mode 100644 validation/bitfield-expand-deref.c
diff --git a/expand.c b/expand.c
index f436b5b50..d44cfac73 100644
--- a/expand.c
+++ b/expand.c
@@ -644,6 +644,8 @@ static int expand_dereference(struct expression *expr)
if (value) {
/* FIXME! We should check that the size is right! */
if (value->type == EXPR_VALUE) {
+ if (is_bitfield_type(value->ctype))
+ return UNSAFE;
expr->type = EXPR_VALUE;
expr->value = value->value;
expr->taint = 0;
diff --git a/validation/bitfield-expand-deref.c b/validation/bitfield-expand-deref.c
new file mode 100644
index 000000000..58d1fe176
--- /dev/null
+++ b/validation/bitfield-expand-deref.c
@@ -0,0 +1,27 @@
+struct s {
+ int a:8;
+ int b:8;
+};
+
+int foo(void)
+{
+ struct s x = { .a = 12, .b = 34, };
+
+ return x.b;
+}
+
+int bar(int a)
+{
+ struct s x = { .a = 12, .b = a, };
+
+ return x.b;
+}
+
+/*
+ * check-name: bitfield expand deref
+ * check-command: test-linearize -Wno-decl $file
+
+ * check-output-ignore
+ * check-output-excludes: ret\..*\$12
+ * check-output-contains: ret\..*\$34
+ */
--
2.14.0
next reply other threads:[~2017-08-20 22:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-20 22:16 Luc Van Oostenryck [this message]
2017-08-20 22:19 ` [PATCH] fix expansion of constant bitfield dereference Dibyendu Majumdar
2017-08-21 12:26 ` Christopher Li
2017-08-21 13:32 ` Dibyendu Majumdar
2017-08-21 13:41 ` Christopher Li
2017-08-21 13:42 ` Luc Van Oostenryck
2017-08-21 16:06 ` Christopher Li
2017-08-21 16:14 ` Luc Van Oostenryck
2017-08-21 16:46 ` Christopher Li
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=20170820221602.27852-1-luc.vanoostenryck@gmail.com \
--to=luc.vanoostenryck@gmail.com \
--cc=linux-sparse@vger.kernel.org \
--cc=mobile@majumdar.org.uk \
/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).