On Wed, May 8, 2024 at 1:25 AM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 7 May 2024 at 07:25, Ryusuke Konishi <konishi.ryusuke@xxxxxxxxx> wrote: > > > > Despite that change, sparse complains when > > passing a bitwise type to is_signed_type(). It is not clear to me why. > > Bah. The reason is this: > > #define is_signed_type(type) (((type)(-1)) < (__force type)1) > > Basically, the way "is_signed_type()" works is that it casts a > negative integer to the type, and checks to see if the value has now > become a large value. > > Now, it looks odd, because only one of those casts has a "__force" on > it, but the reason for that is that casting all-ones and all-zeroes is > ok for bitwise types (think of bitwise types as being a "collection of > bits" - so all bits set or all bits clear are sane concepts regardless > of any other semantics). > > So it's not the casts themselves that are problematic: that part works fine. > > But you cannot compare a random collection of bits for greater than or > lesser than. > > Think of things like byte orders: you can compare two values for > _equality_ even if they are in the wrong byte order, but you can't > compare them for "larger than" unless you turn them into the right CPU > byte order. > > Basically, a "collection of bits" doesn't have an ordering in itself, > even if equality comparisons are ok. > > So yeah, is_signed_type() doesn't work for bitwise types. > > And I don't see a sane way to make "is_signed_type()" to work for > bitwise types - the whole concept of signedness of "bunch of bits" is > kind of nonsensical - so I suspect your workaround is the best we can > do (alternatively, tracing would have to figure out a different way to > test for signedness). > > Linus Linus, thank you very much for your detailed explanation. I would like to edit the quoted part of his commit message > > Despite that change, sparse complains when > > passing a bitwise type to is_signed_type(). It is not clear to me why. as follows: Despite that change, sparse complains when passing a bitwise type to is_signed_type(). The reason is that in its definition below, a comparison will be made against bitwise types, which are random collections of bits (the casts to bitwise types themselves are semantically valid and are not problematic): #define is_signed_type(type) (((type)(-1)) < (__force type)1) So, as a workaround, fix the warnings by using __field_struct() macro that doesn't use is_signed_type() instead of __field(). ... I will try to resend the patch later unless there's a misunderstanding or I'm missing too many points. Thanks, Ryusuke Konishi
