> the kernel relies on this not being "optimized away" by the compiler > in many places. I think "undefined behavior" is the more general topic, more important than null pointer checks specifically? > the kernel relies on the compiler to be sane :) Undefined behavior is... insane by essence? I'm afraid a few custom compiler options can never fully address that. While we might get away with -fno-delete-null-pointer-checks right here right now, who knows what else could happen in some future compiler version or future combination of flags. No one: that's why it's called "undefined" behavior! > If "tooling" trips over stuff like this, then we should fix the tooling Because of its old age, many quirks and limitations, C needs and has a pretty large number of external "tools": static and run-time analyzers, coding rules (CERT, MISRA,...) and what not. It's not realistic to "fix" them all so they all "support" undefined behaviors like this one. It's already hard enough for them to agree on false positives with a somewhat "standard" version of C. The kernel wields a massive influence but I'm afraid its power is not big enough to impose its own C "flavor". It has influence on gcc and a couple others but not on the language as a whole. The alternative is for the kernel to stay incompatible by choice with most C "tooling" available - and find fewer issues :-( (For even more diverse language mess, take a look at the Safe C++ "standardization" attempt and at C++ "profiles". I digress) > I see a similar case with discussion at: > https://lore.kernel.org/lkml/3f1e7aaa-501a-44f1-8122-28e9efa0a33c@xxxxxx/ Thanks Miguel for these near-identical examples. While more verbose and more error-prone, this can indeed be fixed with pre-C99, separate definitions as it was done in multiple places there. This is just moving one line of code a few lines down. I think there are many more "interesting" and much more complex C flaws to waste time on :-) My 2 cents.
