On 02.06.2012 0:06, Dmitry Olshansky wrote:
On 01.06.2012 23:38, Jonathan M Davis wrote:
On Friday, June 01, 2012 14:00:01 deadalnix wrote:
Le 01/06/2012 12:26, Walter Bright a écrit :
Except that you do not know why the arithmetic turned out wrong - it
could be the result of memory corruption.
Yes. wrong calculation often comes from memory corruption. Almost never
from programmer having screwed up in the said calculation.
It is so perfectly reasonable and completely match my experience. I'm
sure everybody here will agree.
Not to mention that said memory corruption obviously come from compiler
bug. As always. What programmer does mistakes in his code ? We write
programs, not bugs !
I'd have to agree that the odds of an arithmetic error being caused by
memory
corruption are generally quite low, but the problem is that when an
assertion
fails, there's _no_ way for the program to know how bad things really
are or
what the cause is.
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.
By the way memory corruption is checkable. And even recoverable, one
just needs to have certain precautions like adding checksums or better
yet ECC codes to _every_ important data structure (including of course
stack security hashes). Seems very useful for compiler generated code
with '-debug' switch. It even can ask GC to recheck ECC on every GC
datastructure. Do that memory check on each throw of error dunno. Trust
me to do the thing manually I dunno. Provide some options, damn it.
For all I care the program is flawless it's cosmic rays that are funky
in this area.
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.
Ah, forgot the most important thing: I'm not convinced that throwing
Error that _loosely_ _unwinds_ stack is better then straight abort on
spot or _proper_ stack unwinding. nothrow is not argument of itself.
I've yet to see argument for what it gives us that so important.
(C++ didn't have proper nothrow for ages, it did worked somehow)
BTW stack can be corrupted (in fact it's quite often is, and that's most
dangerous thing). Even C's runtime abort can be corrupted. Mission
critical software should just use straight HALT instruction*.
So point is don't get too paranoid by default please.
Yet it will leave things that this program operates on in undefined
state, like half-open airlock.
--
Dmitry Olshansky
