Should we warn if we detect null derefernces or void value uses ?

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Wed Dec 7 02:25:56 PST 2016


On 12/4/2016 8:41 PM, Stefan Koch wrote:
> What is your opinion, should we warn if we unambiguously detect something that
> is clearly unwanted ?
>
> int fn(int y)
> {
>   int x = void;
>   ++x;
>   return x+y;
> }

It's an old idea, and comes up regularly.

This all sounds like a great idea, and I've tried it. Unfortunately, it runs 
afoul of code like this:

   int i;
   int* p = null;
   if (c)
     p = &i;
   ...code...
   if (c)
     *p = 3; // Warning Will Robinson! p could be null!

Now, one could say "improve the flow analysis to prove that the first `if(c)` is 
the same as the second `if(c)`. Unfortunately, `c` can be arbitrarily complex 
and it is one of those unresolvable problems proving that two expressions 
produce the same result, even if the programmer finds it obvious.

Does this happen in real code? As I discovered, yes. Often enough that I had to 
back out that feature.

[Other, more subtle issues like this can come from machine generated code paths 
that will never execute, but are difficult to not generate. So the poor schleb 
writing the generator has to spend a lot of time on this to work around 
shortcomings in the compiler flow analysis - and he'll be guaranteed to not be 
happy about it.]



More information about the Digitalmars-d mailing list