Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 5 Jul 2017 12:07:42 -0700 | Subject | Re: [GIT PULL] gcc-plugins updates for v4.13-rc1 |
| |
Hmm. Completely unrelated comment, and this may not be a gcc 'plugin' issue as much as a more general gcc question, but I suspect a plugin could do it.
For the kernel, we already really ignore some of the more idiotic C standard rules that introduce pointless undefined behavior: things like the strict aliasing rules are just insane, and the "overflow is udnefined" is bad too. So we use
-fno-strict-aliasing -fno-strict-overflow -fno-delete-null-pointer-checks
to basically say "those optimizations are fundamentally stupid and wrong, and only encourage compilers to generate random code that doesn't actually match the source code".
And I suspect one other undefined behavior is the one we _try_ to warn about, but where the compiler is not always good enough to give valid warnings - uninitialized automatic variables.
Maybe we could have gcc just always initialize variables to zero. Not just static ones, but the automatic variables too. And maybe it wouldn't generate much extra code, since gcc will see the real initialization, and the extra hardening against random behavior will just go away - so this might be one of those cheap things where we just avoid undefined behavior and avoid leaking old stack contents.
Yes, yes, you'd still have the uninitialized variable warning, but that doesn't catch the case where you pass a structure pointer to a helper that is *supposed* to fill it in, but misses a field or just misses padding.
And maybe I'm wrong, and maybe it would generate a lot of really bad extra zeroing and wouldn't be acceptable for most people, but I *think* this might be one of those things where we might get some extra belt and suspenders kind of hardening basically for free..
Comments?
Linus
| |