<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
NIL might be a special case.<BR>
But by and large, continuing to do anything after a SIGSEGV is a bad idea.<BR>
You think (you say) you are continuing on and preserving state, but the state<BR>
of the world is now arbitrarily altered and unknown and all future computation<BR>
based on it is suspect. Best to throw it away. And avoid incorrect results<BR>
when there is a such a strong hint that things have gone awry.<BR>
<BR>
<BR>
In the Windows C programming world, you can catch access violatios (SIGSEGV)<BR>
very easily with __except. But prevailing wisdom now and for a long time is<BR>
exactly what I'm saying -- that catching and continuing isn't "robust", it is letting<BR>
the damage of bugs continue further.<BR>
<BR>
<BR>
I'm undecided as to the level of guarantees of the safety guarantees, given<BR>
the surrounding unsafe world. I believe safety depends on a lack of bugs<BR>
in certain places, certain fairly large places, and therefore the safety<BR>
guarantees should be considered significant and useful, but not absolute.<BR>
<BR>
<BR>
There really are bugs everywhere. In the compiler (Modula-3, C, etc.),<BR>
in the C runtime, in the kernels, in the CPUs.<BR>
Recent AMD processors have a bug in integer division even..one of the<BR>
most surprising things I've seen in a long time..<BR>
(really, recent processors, integer division, I'm not talking about the ancient<BR>
Pentium FDIV bug).<BR>
There is a published errata for it and it has been fixed.<BR>
But I managed to hit it in my code..<BR>
<BR>
<BR>
- Jay<BR> <BR>
> To: jay.krell@cornell.edu<BR>> Date: Sat, 19 Feb 2011 16:13:14 -0800<BR>> From: mika@async.caltech.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] SEGV mapping to RuntimeError<BR>> <BR>> Jay K writes:<BR>> >--_1802b75d-f353-43c9-bd6c-02a34e2b7ae8_<BR>> >Content-Type: text/plain; charset="iso-8859-1"<BR>> >Content-Transfer-Encoding: quoted-printable<BR>> ><BR>> ><BR>> >Modula-3 doesn't live in a vacuum.<BR>> >The vast majority of surrounding code is C and C++.<BR>> >There are bugs everywhere.<BR>> > - Jay<BR>> <BR>> It's rather up to the programmer using it, isn't it? If you write your<BR>> code in pure Modula-3, you should be able to rely on the guarantees of<BR>> the Green Book (and therefore that SIGSEGV means something relatively<BR>> specific, not that "the world just ended"). If you insist on linking<BR>> with broken C and C++... well you get what you deserve, probably best<BR>> not to try to handle RuntimeError.E in that case.<BR>> <BR>> In any case, to an interactive user of my Scheme interpreter it is very<BR>> useful that a NIL dereference drops him at the read-eval-print loop<BR>> rather than killing the world. E.g., if as I had yesterday, a 1-gigabyte<BR>> datastructure parsed in memory, and I lost the world because I happened<BR>> to try to set-car! on a null list somewhere.<BR>> <BR>> Mika<BR> </body>
</html>