From: Linus Torvalds <torvalds@linux-foundation.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-nilfs@vger.kernel.org, linux-kernel@vger.kernel.org,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Steven Rostedt <rostedt@goodmis.org>,
Ryusuke Konishi <konishi.ryusuke@gmail.com>
Subject: Re: [PATCH -mm] nilfs2: Use __field_struct() for a bitwise field
Date: Fri, 17 May 2024 08:52:34 -0700 [thread overview]
Message-ID: <CAHk-=wh9cwmRUzqskD=qV2oCpyS8GBWWAv1sSrN8YOPR3fd70w@mail.gmail.com> (raw)
In-Reply-To: <4a5cf233-a4e6-48ce-b9ba-f1014f452892@acm.org>
On Thu, 16 May 2024 at 14:52, Bart Van Assche <bvanassche@acm.org> wrote:
>
> It seems like sparse verifies the types of all expressions in a
> _Generic() argument list instead of only the expression for which the
> type matches.
Yes.
> Could this indicate a bug in sparse? On
> https://en.cppreference.com/w/c/language/generic I found the
> following (I'm not sure whether that website is a good reference):
>
> "The controlling-expression and the expressions of the selections that
> are not chosen are never evaluated."
Not really a bug, because "never evaluated" in the above context means
that they don't generate code. The expressions are still obviously
parsed for syntax and validity.
It definitely might be seen as a misfeature, though - the "degrades to
integer" warning is done before code reachability has been determined.
So it's done even for code that is never executed.
So you'd get it even if you had something like
if (0) .. some bad bitwise expression ...
Sadly, that's fairly deeply ingrained in how sparse deals with the
bitwise types: they degrade to their regular base type as part of the
type evaluation, which happens fairly early on the syntax tree, long
before it has been converted to SSA form and reachability analysis.
It's *fixable* - instead of warning when evaluating the types of the
expression, sparse could leave in a "warning node" into the tree,
linearize it to a "warning instruction" in the SSA form, and only
actually output a warning if that instruction still exists after dead
code elimination etc.
But that kind of fix would be a pretty big change, we don't have that
kind of thing right now at all. So "fixable in theory" is probably not
"practical with the current lack of sparse development".
What would be much easier is probably to hack together a couple of
builtins for type checking: a "__builtin_signed_p()" should not be
hard.
Linus
prev parent reply other threads:[~2024-05-17 15:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 14:24 [PATCH -mm] nilfs2: Use __field_struct() for a bitwise field Ryusuke Konishi
2024-05-07 16:25 ` Linus Torvalds
2024-05-07 21:05 ` Ryusuke Konishi
2024-05-16 21:51 ` Bart Van Assche
2024-05-17 15:52 ` Linus Torvalds [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='CAHk-=wh9cwmRUzqskD=qV2oCpyS8GBWWAv1sSrN8YOPR3fd70w@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=bvanassche@acm.org \
--cc=konishi.ryusuke@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nilfs@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=rostedt@goodmis.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).