On Wed, Oct 19, 2022 at 10:14 AM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > The pointer-sign thing doesn't actually help (ie it won't find places > where you actually compare a char), and it causes untold damage in > doing completely insane things. Side note: several years ago I tried to make up some sane rules to have 'sparse' actually be able to warn when a 'char' was used in a context where the sign mattered. I failed miserably. You actually can see some signs (heh) of that in the sparse sources, in that the type system actually has a bit for explicitly signed types ("MOD_EXPLICITLY_SIGNED"), but it ends up being almost entirely unused. That bit does still have one particular use: the "bitfield is dubiously signed" thing where sparse will complain about bitfields that are implicitly (but not explicitly) signed. Because people really expect 'int a:1' to have values 0/1, not 0/-1. But the original intent was to find code where people used a 'char' that wasn't explicitly signed, and that then had architecture-defined behavior. I just could not come up with any even remotely sane warning heuristics that didn't have a metric buttload of false positives. I still have this feeling that it *should* be possible to warn about the situation where you end up doing an implicit type widening (ie the normal C "arithmetic is always done in at least 'int'") that then does not get narrowed down again without the upper bits ever mattering. But it needs somebody smarter than me, I'm afraid. And the fact that I don't think any other compiler has that warning either makes me just wonder if my feeling that it should be possible is just wrong. Linus