On Saturday, February 01, 2014 19:40:26 Andrei Alexandrescu wrote: > On 2/1/14, 7:29 PM, Jonathan M Davis wrote: > > Sure, and there are other things that the compiler can do to catch null > > dereferences (e.g. look at the first dereferencing of the pointer in the > > function that it's declared in and make sure that it was initialized or > > assigned a non-null value first), but the only way to catch all null > > dereferences at compile time would be to always know at compile time > > whether the pointer was null at the point that it's dereferenced, and > > that can't be done. > > What are you talking about? That has been done.
How so? All that's required is something like auto ptr = foo(); if(bar()) //runtime dependent result ptr = null; ptr.baz(); and there's no way that the compiler could know whether this code is going to dereference null or not. Sure, it could flag it as possible and thus buggy, but it can't know for sure. And an even simpler case is something like auto ptr = foo(); ptr.baz(); The compiler isn't going to know whether foo returns null or not, and whether it returns null could depend on the state at runtime, making it so that it can't possibly know whether foo will return null or not. And even if foo were as simple as Bar* foo() { return null; } the compiler would have to actually look at the body of foo to know that its return value was going to be null, and compilers that use the C compilation model don't normally do that, because they often don't have the body of foo available. So, maybe I'm missing something here, and maybe we're just not quite talking about the same thing, but it's my understanding that it is not possible for the compiler to always know whether a pointer or reference is going to be null when it's dereferenced unless it's actually illegal for that pointer or reference type to be null (be it because of its type is non-nullable or an annotation marks it as such - which effectively then changes its type to non- nullable). As soon as you're dealing with an actual, nullable pointer or reference, it's trivial to make it so that the compiler doesn't have any idea what the pointer's value could be and thus can't know whether it's null or not. Sections of code which include the initialization or assignment of pointers which are given either new or null certainly can be examined by the compiler so that it can determine whether any dereferencing of that pointer that occurs could be dereferencing null, but something as simple as making it so that the pointer was initialized from the return value of a function makes it so that it can't. > > AFAIK, the only solution that guarantees that it catches all dereferences > > of null at compile time is a solution that disallows a pointer/reference > > from ever being null in the first place. > > Have you read through that link? Yes. And all I see is that @Nullable makes it so that some frameworks won't accept null without @Nullable, which effectively turns a normal Java reference into a non-nullable reference. I don't see anything indicating that the compiler will have any clue whether an @Nullable reference is null or not at compile time. My point is that when a nullable pointer or reference is dereferenced, it's impossible to _always_ be able to determine at compile time whether it's going to dereference null. Some of the time you can, and using non-nullable, references certainly makes it so that you can, because then it's illegal for them to be null, but once a reference is nullable, unless the compiler knows the entire code path that that pointer's value goes through, and that code path is guaranteed to result in a null pointer or it's guaranteed to _not_ result in a null pointer, the compiler can't know whether the pointer is going to be null or not at the point that it's dereferenced. And you can't even necessarily do that with full program analysis due to the values potentially depending on runtime state. You could determine whether it _could_ be null if you had full program analysis, but you can't determine for certain that it will or won't be - not in all circumstances. And without full program analysis, you can't even do that in most cases, not with nullable references. But maybe I'm just totally missing something here. I suspect though that we're just not communicating clearly enough for us to quite get what the other is saying. - Jonathan M Davis