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
