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