🚀 go-pugleaf

In article <436@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes:
>In article <14833@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>> In a Unix system I am designing, I am considering catering to bad
>> code. That is, like the VAX I propose to make location 0 contain a
>> readable 0.
>> What do people think of this? Is it kind of disgusting?
>
>I agree with Rob and others who have said No (don't do it) and Yes
>(it's disgusting).
>
>It's not just location 0.  It's all small integers, positive and
>negative.
> ...
>Use of location 0 is a bug.  It is not portable to many machines and
>operating systems (e.g. VMS).  And lots of early UNIX programs do it. :^(
>-- 

When we were designing Celerity's first product, I pushed for trapping on
page 0 references.  I lost out to arguments much like those here in the
news.  We also took no special precaution to see that address 0 has a 0 in
it.  In retrospect, I think we would have been better off making page 0
unreferencable.

Almost all Celerity a.out's begin with the string 0x10, 0x80, 0x51, 0x0.
Using 0 as a pointer is now affectionately referred to as 'The Q bug',
referring to its visible attributes when printed as a string.  The net
effect was that 'Q bugs' were common, most of which were relatively
harmless, but enough of which were quite nasty.  Because we don't trap, it
is hard to say how many of these bugs exist today.

Due to the way Celerity manages shared text using a context identifier in
the hardware, the kernel can distinguish a fetch-for-execute from a
fetch-for-data.  It can take special action (e.g., signal the process) on
page 0 fetch-for-data references.  To fix a number of hard-to-find bugs I
have had to generate kernels to do exactly that for in-house developer use.
Someone was in my office yesterday asking if I still had that kernel around
(we never productized this behavior for the same reasons that we didn't make
page 0 unreferencable.  A site-configurable implementation is possible but
has never been proposed).

I still can't accept the argument that says that a machine should be
designed to tolerate a certain class of bad code.  The problem exists due to
the fact that machines tolerated it in the first place.  Would you argue
that a machine should return 0 if a program accesses undefined virtual
memory? (or -1, maybe? ;-)).