On Thu, Oct 1, 2009 at 1:38 PM, Nick Sabalausky <a...@a.a> wrote:
>> 2. possible dereference of NULL pointers (some reaching definitions of a
>> pointer are NULL)
>> 2. Optimizer collects the info, but ignores this, because people are
>> annoyed by false positives.
>>
>
> If you mean something like this:
>
> Foo f;
> if(cond)
> f = new Foo();
> f.bar();
Probably more like
Foo f;
createAndSetOutParam(f);
f.bar();
or
Foo f;
if (a > 10) { f = new Foo(10); }
...
if (a > 10) {
f.bar();
}
Or some complex intertwined gotos or any number of other things that
would be hard for the compiler to verify without a lot of effort.
I think I'd want to try this out as an optional warning for a while to
see how annoying the false positives really are in practice. Still,
it seems like there's a subset of cases where it can be proved with
100% certainty that the code is wrong. Just reporting those cases
would be a big win, I think.
> Then I *want* the compiler to tell me. C# does this and I've never been
> annoyed by it, in fact I've always appreciated it. I'm not aware of any
> other C# user that has a problem with that either. If that's not what you
> mean though, then could you elaborate?
How does C# handle the cases above?
>> 6. array overflows
>> 6. Arrays are solidly covered by a runtime check. There is code in the
>> optimizer to detect many cases of overflows at compile time, but the code
>> is currently disabled because the runtime check covers 100% of the cases.
>>
>
> I'm puzzled by why you would prefer to leave this entirely runtime when some
> of it can be detected at compile-time. Normally you agree that catching
> something at compile-time is better whenever possible. So shouldn't the
> array overflows that can be detected at compile-time be detected at
> compile-time? I would certainly prefer that.
I agree. Run-time checks are only useful if the code is on a path that
actually runs. Compile-time checks are useful even if the code is on
the branch not taken.
--bb
