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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Sat, Jun 25, 2022 at 05:44:54PM -0700, Bart Van Assche wrote:
> On 6/25/22 02:23, Christoph Hellwig wrote:
> > On Fri, Jun 24, 2022 at 12:57:56PM -0700, Bart Van Assche wrote:
> > > BTW, I discovered the code in the tracing infrastructure
> > > that makes sparse unhappy:
> > > 
> > > #define is_signed_type(type) (((type)(-1)) < (type)1)
> > > 
> > > Sparse reports four warnings for that expression if 'type' is a bitwise
> > > type. Two of these warnings can be suppressed by changing 'type' into
> > > '__force type'. I have not yet found a way to suppress all the sparse
> > > warnings triggered by the is_signed_type() macro for bitwise types.

Yes, __bitwise is quite strict and only support the bitwise operations
(&, |, ^ and).
> > 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

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)?

Implementing directly what's needed here, something like __is_signed_type()
would be possible too but is a bit too specialized and so much less useful.

-- Luc Van Oostenryck

[Index of Archives]     [Newbies FAQ]     [LKML]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Trinity Fuzzer Tool]

  Powered by Linux