[M3devel] SEGV mapping to RuntimeError

[Mika Nystrom]

Jay K writes:
> - You can't get SIGSEGV w/o memory protection. SIGSEGV is generated by har=
>dware.
>=20

I'm not interested in SIGSEGV per se.  The point is to map whatever
bad memory reference can be generated by non-UNSAFE code to a
RuntimeError.E.  If you have the hardware to do that, you use it.
A Modula-3 implementation on a system without memory protection would
have to generate RuntimeError.E using a different mechanism.

> - Untrusted code should not be run in-process=2C at least unsafe untrusted=
> code.

Why not?  If you can prove it can't cause damage, then it can't.  Why should
Java be able to run untrusted code and not we?

>=20
> - I don't have to reboot my computer for SIGSEGV=2C but individual process=
>es are killed.

It's the same argument.  Why do you trust your kernel?  It's buggy too!  If
a program crashes, better to reboot the machine to be sure you didn't infect
something else.  Heck, unplug it for three minutes just to make sure...

>   The damage is contained as soon as it is detected. The nice thing about =
>safe languages
>    is the error is caught just before any damage is caused=2C i.e. array b=
>ounds checking.

My point exactly.  No reason to start from a clean slate, if you have
some obvious earlier place to jump back to.

All the examples I've given of situations where it's useful to catch the
RuntimeError.E corresponding to SIGSEGV are systems that can be thought
of as pseudo-OSes.  You have a "job" or "process" doing something within
the context of a larger system, or at least there are levels of trust.
You're running "an untrusted module" or "a user command".  I won't call
them "processes" because the terminology would get confusing, but it's
the same idea.  If one of these modules crashes, there is really no need
to abort the whole world, and it would be extremely annoying to user(s)
to have to do so.

     Mika