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

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.

Another question is how to keep the non-sparse build working. Does
anyone want to comment on the following alternatives or propose another

(1) sparse implements __strip_bitwise as a macro.

(in compiler.h)

#ifndef __strip_bitwise
#define __strip_bitwise(type) type

(in trace_events.h)

#define is_signed_type(type) ((__strip_bitwise(type))(-1) < (__strip_bitwise(type))1)

(2) sparse implements __strip_bitwise as an operator that works on types.

#ifdef __CHECKER__
#define is_signed_type(type) ((__strip_bitwise(type))(-1) < (__strip_bitwise(type))1)
#define is_signed_type(type) (((type)(-1)) < (type)1)

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



[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