On Sat, Oct 06, 2018 at 01:52:03PM -0600, Jeff Law wrote: > On 10/5/18 3:53 PM, Segher Boessenkool wrote: > > On Fri, Oct 05, 2018 at 03:30:47PM -0600, Jeff Law wrote: > >> On 10/5/18 3:14 PM, Josef Wolf wrote: > >>> > >>> - If the compiler can detect such a serious problem, then it should emit a > >>> warning AT COMPILE TIME. > >> We don't for various reasons. Frankly, I think we should as well, but I > >> lost that battle. > > > > There is -Wnull-dereference. > Yea, but our implementation is so lame that it's effectively useless. > It only warns out of the front-end and only does so for an explicit *0 > that can be seen without any constant propagation or path isolation. Ah, that is not so great :-( > > If you want the compiler to warn every time there *could* be a null > > dereference, well, how many false positives will that be? ;-) > It's really not bad if you do it late and focus just on whether or not > you can see a NULL pointer flowing into a dereference. If you can see under some given condition there will definitely be a null deref, then yeah that will be useful. Could put a trap there too. Or don't do the test for it if not otherwise needed, just warn at compile time. Such a warning whould be fine for -Wall, too, which makes it a lot more useful. If the current implementation is so restricted, why is it not in -Wall? It shouldn't give many fals positives? > I'd certainly agree that it'd be too noisy to warn if you had a random > pointer of unknown value that gets dereferenced. It could be zero and > warning for all those would be useless in practice. Yeah exactly :-) Segher
