Re: [PATCH 51/51] fs/zonefs: Fix sparse warnings in tracing code

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

On Sun, Jun 26, 2022 at 08:42:27AM -0700, Bart Van Assche wrote:
> On 6/26/22 02:58, Luc Van Oostenryck wrote:
> > On Sat, Jun 25, 2022 at 05:44:54PM -0700, Bart Van Assche wrote:
> > > On 6/25/22 02:23, Christoph Hellwig wrote:
> > > > Yeah, that is a bit of a mess.  Rasmus, Steven - any good idea how
> > > > we can make the trace even macros fit for sparse?  Maybe just drop the
> > > > is_signed_type check for __CHECKER__ ?
> > 
> > I would strongly advise against this:
> > -) the macro is sued elsewhere too (for overflow checking)
> > -) sparse wouldn't check anymore the same code as the one seen by the
> >     compiler
> > 
> > What about I would add to sparse something to strip away the bitwise/
> > recover the underlying type? Something like __unbitwiseof() or
> > __underlying_typeof() (some better name is needed)?
> 
> Another question is how to keep the non-sparse build working. Does
> anyone want to comment on the following alternatives or propose another
> alternative?
> 
> (1) sparse implements __strip_bitwise as a macro.
> 
> (in compiler.h)
> 
> #ifndef __strip_bitwise
> #define __strip_bitwise(type) type
> #endif

...

> (1) would work better than (2) for kernel developers who are using a
> version of sparse that does not support __strip_bitwise().

Yes, sure. I was thinking about using (and adding) __has_feature()
but the goal is the same.

[I prefer this because, internally, an operator is needed anyway and
__has_feature() would be more general (but then it would need to be
protected by its own #ifndef __has_feature).]

-- Luc