Received-SPF: pass (google.com: domain of linux-kernel+bounces-182318-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240507142454.3344-1-konishi.ryusuke@gmail.com>
 <CAHk-=wgogPoSdCYw9jhc2Zm=BaE19nXYwFn_F9SwD2C-DyrmCw@mail.gmail.com> <4a5cf233-a4e6-48ce-b9ba-f1014f452892@acm.org>
In-Reply-To: <4a5cf233-a4e6-48ce-b9ba-f1014f452892@acm.org>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 17 May 2024 08:52:34 -0700
Message-ID: <CAHk-=wh9cwmRUzqskD=qV2oCpyS8GBWWAv1sSrN8YOPR3fd70w@mail.gmail.com>
Subject: Re: [PATCH -mm] nilfs2: Use __field_struct() for a bitwise field
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>
Content-Type: text/plain; charset="UTF-8"

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