<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
I just don't think because the Green Book says something, or because it is inherent in the<BR>
design, that is necessarily true or inherent in the implementation.<BR>
There are bugs *everywhere*, and they gradually chip away at all aspects of correctness.<BR>
<BR>
Much of this, there is nothing you can do about.<BR>
The integer divide bug is an example that there is precious little you can do about.<BR>
You can check that the errata is fixed, and not depend on the correctness until<BR>
you have first check for it, but inevitably tons and tons of code will run<BR>
before your correctness check (e.g. booting the OS) and so the state is already not guaranteed.<BR>
<BR>
I've also had my code fail to page in. That is another thing you can't do anything about,<BR>
in usermode...except maybe keep your code to under a page in size. :)<BR>
Simple progressing from one line of code to the next, or pieces within the line, can fail.<BR>
<BR>
But SIGSEGV I think is in another realm. It is a sign of problems that should generally<BR>
be ignored.<BR>
There is a term "fail fast" -- at a sign of problem, fail. Don't press on.<BR>
There are arguments either way.<BR>
The world, really, the larger human enterprise and setting, is not fail fast.<BR>
We have lots of problems, yet almost everything almost always goes on.<BR>
<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>
> To: jay.krell@cornell.edu<BR>> Date: Sat, 19 Feb 2011 16:59:04 -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>> >--_e4a53a7c-4058-44e7-bcce-18b6ae35efbe_<BR>> >Content-Type: text/plain; charset="iso-8859-1"<BR>> >Content-Transfer-Encoding: quoted-printable<BR>> ><BR>> ><BR>> >NIL might be a special case.<BR>> >But by and large=2C continuing to do anything after a SIGSEGV is a bad idea=<BR>> >.<BR>> >You think (you say) you are continuing on and preserving state=2C but the s=<BR>> >tate<BR>> >of the world is now arbitrarily altered and unknown and all future computat=<BR>> >ion<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>> Let's try this again.<BR>> <BR>> The Green Book unequivocally says that non-UNSAFE code can't get the<BR>> world into a "state arbitrarily altered and unknown." That doesn't<BR>> depend on the special case NIL, that's inherent in the design of the<BR>> language and runtime.<BR>> <BR>> Yet non-UNSAFE code can (for efficiency reasons of the implementation)<BR>> cause a SIGSEGV. <BR>> <BR>> If the state of the world is somehow arbitrarily altered and unknown I<BR>> would suggest tracking down the bugs (in UNSAFE code, compiler, C code,<BR>> wherever) and fixing them rather than repeating the C programmer's mantra<BR>> that SIGSEGV is or ought to be fatal to the point that you need to start<BR>> from a clean slate.<BR>> <BR>> This sort of thing is precisely what Modula-3 was invented for!!!!<BR>> Why do you think (crazy) people still use the programming language,<BR>> fifteen years after it's been declared dead? <BR>> <BR>> By the way, every year that I teach a class, I always ask the students<BR>> what programming languages they use/learn/want to learn. Over the years<BR>> I've seen a steady progression of C++, Java, Python... until last year.<BR>> The most popular answer was "C". I must say it felt a bit odd to be,<BR>> technologically, 20 years ahead of people 20 years younger. Now,<BR>> I always used to feel a bit bad about forcing students to study a<BR>> "dead" programming language that would not help them in employment,<BR>> research, etc. (Modular-3? What's that?) But better than a language<BR>> that should be dead.<BR>> <BR>> Mika<BR> </body>
</html>