runtime hook for Crash on Error

[Dmitry Olshansky]

On 02.06.2012 0:52, Walter Bright wrote:
> On 6/1/2012 1:06 PM, Dmitry Olshansky wrote:
>> Indeed it's quite bad to assume both extremes - either "oh, my god
>> everything is
>> corrupted" or "blah, whatever, keep going". I thought D was trying to
>> hold keep
>> reasonable compromises where possible.
>
> D has a lot of bias towards being able to mechanically guarantee as much
> as possible, with, of course, allowing the programmer to circumvent
> these if he so desires.
>
> For example, you can XOR pointers in D.
>

Thanks. Could come in handy one day :)


> But if I were your program manager, you'd need an extraordinary
> justification to allow such a practice.

http://en.wikipedia.org/wiki/XOR_linked_list

>
> My strongly held opinion on how to write reliable software is based on
> decades of experience by others in the aviation business on how to do
> it. And the proof that this works is obvious.
>
No argument here. Planes are in fact surprisingly safe transport.

> It's also obvious to me that the designers of the Deep Water Horizon rig
> and the Fukishima plant did not follow these principles, and a heavy
> price was paid.
>
> D isn't going to make anyone follow these principles - but it is going
> to make it more difficult to violate them. I believe D should be
> promoting, baked into the design of the language, proven successful best
> practices.
>

I'm just hope there is some provision to customize a bit what exactly to 
do on Error. There might be few things to try before dying. Like close 
the airlock.

> In programming courses and curriculum I've seen, very little attention
> is paid to this, and programmers are left to discover it the hard way.
>

That's something I'll agree on. I've had little exposure to in-house 
firmware design. It's not just people or skills but the development 
process that is just wrong. These days I won't trust a toaster with 
"smart" MCU in it. Better old analog stuff.

>> Certain compilers by the way already do something like that on each stack
>> entry/leave in debug mode (stack hash sums).
>>
>> P.S. Trying to pour more and more of "generally impossible" "can't do
>> this",
>> "can't do that" and ya-da-ya-da doesn't help solving problems.
>
> It doesn't even have to be memory corruption that puts your program in
> an invalid state where it cannot reliably continue.

Point was memory corruption is hard to check. Yet it's quite checkable. 
Logical invariants in fact easier to check. There are various other 
techniques to make sure if global state is intact and what parts of it 
can be save and so on. Trying to cut all of it down with single cure is 
not good.
Again I'm speaking of options here, pretty much like XORing a pointer 
they are surely not everyday thing.

The assert would
> have detected a logic bug, and the invalid state of the program is not
> at all necessarily memory corruption. Invalid does not imply corruption,
> though corruption does imply invalid.

Correct.

-- 
Dmitry Olshansky