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
