🚀 go-pugleaf

In article <636@brl-sem.ARPA>, ron@brl-sem.ARPA (Ron Natalie <ron>) writes:
> I like the GOULD approach.  The board that traps access to location 0
> among other out of bound memory addresses can be set to just ignore
> the attempt (the user appears to have accessed the location, but doesn't
> get anything if it is outside his memory limits, 0 is never in a user
> address space there), print a message in the logfile, or memory fault
> the process (and print a message in the log file).  This allows you
> to turn on carefull mode or revert to VAX bad-code compatibility mode.

Only the last option is acceptable, because:

1.  Ignoring the attempt to access unmapped address: hides a bug that could
	be caught at the disallowed access and may manifest itself in an
	unbelievably obscure manner later.  Or, since the action of the
	program with this option might be the intended one, the bug is
	not detected, not fixed, and pops up sometime later in the
	development cycle (during porting) when it is much more expensive
	to fix.
2.  Printing a message in a log file: too easy to miss; how do you correlate
	the message with the access that caused it?  A core dump tells you
	exactly where the bug is and what the environment was at the time.
3.  Memory fault: that's what the access is, a memory fault, and the system
	should stop right then and there because further execution will only
	mask the bug more.

A point was brought up by a software user where he mentioned that time is
wasted when a program core dumps.  This is true, but the alternative can be
much more costly.  If the program accesses an unmapped address, it has a bug
in it, and is therefore not correct.  Its results are suspect, and it is
better that it inform the user in no uncertain manner that it is doing
something wrong rather than go on and produce wrong answers that might
look OK.
--
	Mike Klein		klein@sun.{arpa,com}
	Sun Microsystems, Inc.	{ucbvax,hplabs,ihnp4,seismo}!sun!klein
	Mountain View, CA