All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.e.keller@intel.com>
To: linux-sparse@vger.kernel.org
Cc: Jacob Keller <jacob.e.keller@intel.com>
Subject: [PATCH] sparse: only warn about directly nested flexible arrays
Date: Tue, 11 Jan 2022 15:39:59 -0800	[thread overview]
Message-ID: <20220111233959.2301120-1-jacob.e.keller@intel.com> (raw)

Commit 02ed28909f3b ("flex-array: warn on flexible array in nested
aggregate types") Introduced a new -Wflexible-array-nested warning which
produces a warning when code nests a flexible array aggregate type
within another aggregate type.

This can produce warnings that are difficult to understand if this
becomes nested. Consider the following example code:

struct a {
  int i;
  long f[];
};

struct b {
  struct a a;
};

struct c {
  struct b b;
};

This will produce a warning both at struct b which directly embeds the
struct a, and also at c which happens to include struct a recursively.

It does not make sense to warn at the site of struct c. We already
produce a warning at struct b! This just confuses users and can produce
lots of extra warnings. Consider if struct b was part of some header
and all of its users now see warnings for their usages like 'struct c'
which now look like their fault, when the fault really lies with the
definition of struct b.

To avoid this, stop proliferating has_flexible_array so that the outer
struct no longer produces a warning.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---

This patch is a response to my query at
https://lore.kernel.org/linux-sparse/64238376-3882-2449-7758-e948cb4a6e1c@intel.com/T/#u

I think that proliferating this warning is unnecessary (since it will
produce one warning at the exact point where we embed the structure already)
and avoids confusing users of a header into thinking their code is at fault
when its the code in the header at fault.

 symbol.c                       | 2 --
 validation/flex-array-nested.c | 9 +++++++--
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/symbol.c b/symbol.c
index 91352a3a447b..d066515fc8ed 100644
--- a/symbol.c
+++ b/symbol.c
@@ -231,8 +231,6 @@ static struct symbol * examine_struct_union_type(struct symbol *sym, int advance
 				info.max_align = member->ctype.alignment;
 		}
 
-		if (has_flexible_array(member))
-			info.has_flex_array = 1;
 		if (has_flexible_array(member) && Wflexible_array_nested)
 			warning(member->pos, "nested flexible array");
 		fn(member, &info);
diff --git a/validation/flex-array-nested.c b/validation/flex-array-nested.c
index 094de2fbc392..81384ec6fd32 100644
--- a/validation/flex-array-nested.c
+++ b/validation/flex-array-nested.c
@@ -11,11 +11,16 @@ union u {
 	struct f f;
 };
 
+struct v {
+	struct s s;
+};
+
 // trigger the examination of the offending types
-static int foo(struct s *s, union u *u)
+static int foo(struct s *s, union u *u, struct v *v)
 {
 	return    __builtin_offsetof(typeof(*s), f)
-		+ __builtin_offsetof(typeof(*u), f);
+		+ __builtin_offsetof(typeof(*u), f)
+		+ __builtin_offsetof(typeof(*v), s);
 }
 
 /*
-- 
2.34.1.182.ge773545c7fe7


             reply	other threads:[~2022-01-11 23:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11 23:39 Jacob Keller [this message]
2022-05-21 12:32 ` [PATCH] sparse: only warn about directly nested flexible arrays Luc Van Oostenryck

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=20220111233959.2301120-1-jacob.e.keller@intel.com \
    --to=jacob.e.keller@intel.com \
    --cc=linux-sparse@vger.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.