Referencing through a null pointer

[Andrew Klossner]

[]

	"I believe Gould calls this feature on their system:
	"Braindamaged VAX compatibility mode.""

We can sit here and smirk about how ideologically impure these fools
are who want a 0 at location 0, but the real world is full of hoary old
programs that run fine on a VAX and fail on the class of systems that
don't have a 0 at 0.  If I'm a computer center manager searching for a
replacement for my aging 11/780's, and my several-megabyte
Bread-and-Butter Application works on system X but not on system Y, how
much credence do you think the Y salesperson will get from me when she
explains that my program has no business dereferencing 0?

This is a real go/no-go decision in a significant number of sales.
Tektronix has eschewed ivory tower arguments in favor of pragmatism and
taken careful pains to put a double 0 at location 0 on all our U**x
graphic workstation products.  This is the *default* behavior; you
can't expect the salesperson to remember to specify the "-braindamage"
switch when compiling the potential customer's application.

[You could take the cynical attitude that, but putting 0 at 0 by
default, we encourage development of buggy software that won't port to
other vendors' systems and so lock our customers into our product line.
I only just thought of that; we never consciously considered this.]

	"So long as your memory management hardware is trapping
	references through a null pointer and printing an error
	message, how about allowing the user to set a switch that will
	cause such illegal trapped references to be handled by an
	emulation routine that will cause a zero to be returned and
	continue execution?"

The obvious performance improvement here is simply to make this a
load-time switch which causes 0 to be put at location 0.  There's no
need to bother with trapping references.

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
                        (andrew%tekecs.tek.com at relay.cs.net)   [ARPA]