On 2014-01-18 07:10, Walter Bright wrote:

> BTW, the following program:
>
>    class C { int a,b; }
>
>    int test() {
>      C c;
>      return c.b;
>    }
>
> When compiled with -O:
>
>    foo.d(6): Error: null dereference in function _D3foo4testFZi
>
> It isn't much, only working on intra-function analysis and only when the
> optimizer is used, but it's something. It's been in dmd for a long time.


Why only when the optimizer is used?

-- 
/Jacob Carlborg

"Jacob Carlborg"  wrote in message news:lbdkvv$2f1n$1@digitalmars.com... 
> Why only when the optimizer is used?

The code that detects the null dereference is in the optimizer.

On Saturday, 18 January 2014 at 03:07:30 UTC, H. S. Teoh wrote:
> You missed his point. The complaint is that the car has a *single*
> software system that handles everything. That's a single point of
> failure. When that single software system fails, *everything* fails.

I didn't miss the point at all. My point is that you should always target the cost of improving the statistical overall safety of the system rather than optimizing the stability of a single part that almost never fail.

Having multiple independent software implementations only works for very simple systems. And in that case you can prove correctness by formal proofs. It is more likely to fail due to a loose wire or electrical components.

On 2014-01-18 11:41, Daniel Murphy wrote:

> The code that detects the null dereference is in the optimizer.

Why is it located there?

-- 
/Jacob Carlborg

On Saturday, 18 January 2014 at 11:03:22 UTC, Jacob Carlborg wrote:
> On 2014-01-18 11:41, Daniel Murphy wrote:
>
>> The code that detects the null dereference is in the optimizer.
>
> Why is it located there?

It's probably flow sensitive and only the optimizer builds a CFG.

"Tobias Pankrath"  wrote in message news:rxnlyzyfkzndzfslvqzp@forum.dlang.org...
>> Why is it located there?
>It's probably flow sensitive and only the optimizer builds a CFG.

Exactly.  It _could_ be done in the frontend, but it hasn't. 

On 1/18/2014 2:02 AM, Namespace wrote:
> Print nothing, even with -O.

Right. As I explained, it is only intra-function analysis.

On 1/18/2014 2:28 AM, Jacob Carlborg wrote:
> Why only when the optimizer is used?

Yes, because the optimizer uses data flow analysis, and this falls out of that.

On Saturday, 18 January 2014 at 00:44:56 UTC, Ola Fosheim Grøstad wrote:
> Big systems have to live with bugs, it is inevitable that they run with bugs. Erlang was created for stuff like that. Can you imagine a telephone central going down just because the settings for one subscriber was wrong and triggered a bug?

Stupid me, that I thought that all this mess was solved decades ago with the CPU protected mode.
I tend to agree with Walter on this front.

--
Paolo

On 2014-01-18 03:38:31 +0000, Walter Bright <newshound2@digitalmars.com> said:

> On 1/17/2014 7:23 PM, Michel Fortin wrote:
>> I guess so. But you're still unconvinced it's worth it to eliminate null
>> dereferences?
> 
> I think it's a more nuanced problem than that. But I agree that compile time detect of null reference bugs is better than runtime detection of them.

In the C++ project I'm working on (full of asynchronous callbacks) I've built myself a not-null smart pointer type. It tries to disallow things at compile time, but because it can't follow control flow there's obviously some possible leaks that are caught at runtime through an assertion upon assignment. I created it because I had some untraceable bugs and I though it'd be simpler to convert the code base to use not-null pointers than it'd be to narrow the issues manually. The transition was surprisingly easy: just try to make everything you can not-nullable. Sometime the logic forces you to make a variable nullable, sometime you discover a bug in the form of a missing null check.

Implementing non-nullable pointers and adapting the code base was worth it for me. I found some bugs that I couldn't track otherwise, and some others that had yet to occur. But more importantly now when I look at a pointer in this project I know immediately from its declaration whether that pointer can be null or not, and I find that very helpful when tweaking code that was written a while ago.

But in the process I've created a new meta-language (make_new< T > instead of new, a new smart pointer types, cast function for those pointers, etc.) that someone new on the project will have to learn and train himself to use correctly. Integrating the thing in the language would make things that much simpler because it'd preserve the normal syntax of the language and also because null leaks can all be detected at compile-time, with clearer error messages.

This is what motivated my proposal earlier in this thread. I'm proposing an improved version of what I'm already using currently:
http://forum.dlang.org/thread/lba1qe$1sih$1@digitalmars.com?page=4#post-lbbgr6:247sf:241:40digitalmars.com

I'd 

like to know what you think of it.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca