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.
--
Dmitry Olshansky
