Path: utzoo!utgpu!attcan!uunet!mcvax!cernvax!ethz!iis!prl
From: prl@iis.UUCP (Peter Lamb)
Newsgroups: comp.arch
Subject: Re: Software Distribution
Message-ID: <634@eiger.iis.UUCP>
Date: 29 Sep 88 00:58:31 GMT
References: <978@esunix.UUCP>
Reply-To: prl@iis.UUCP (Peter Lamb)
Organization: Integrated Systems Lab., ETH Zuerich
Lines: 101

In article <978@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes:
>
>Try this scenario:
>
>There are two kinds of computers in the world, brand X and brand Y.
>Brand X computers define the value pointed to by a NULL pointer to be
>a NULL value. That is, the load indirect instruction given the value
>that C uses for NULL is guaranteed to return NULL.  On the other hand
>brand Y computers core dump if you try to load a value from the
>address that is equivalent to NULL.

Actually there are 4 types; add to the above two types a machine
which returns constant garbage when you dereference NULL, and one which
returns whatever you last wrote into location NULL. Unix also runs
on machines like these...

>
>In all other respects X and Y computers are similar enough in word
>size, data formats, and so on, that software that doesn't dereference
>NULL ports easily from one brand of machine to the other.

That is to say, correct software ports correctly.

> ....

>A programmer uses brand X computers. He writes a pointer chasing
>program that assumes that *NULL == NULL.

He's written incorrect code (in C or similar languages).

>So, the compiler that runs on brand X machines must, at least, put a
>flag in the UIF stating that dereferencing NULL is allowed. The
>compiler on brand Y machines should state that dereferencing NULL is
>not allowed. That way the code can be made to run on any machine,
>though with a preformance hit when the original compilers assumptions
>don't match the reality of a specific machine. Obviously the compilers
>and code generators for brand X machines are going to be set up to
>produce good code for brand X computers and the same is true for brand
>Y computers.  But, it is still possible for UIF code generated for one
>machine to be translated to be run on the other machine.
>

*HOW* are you going to manage this? Even on the VAX, the classical
trap machine for *0 programmers, *0==0 is only true for a few special
cases:
	*(char*)0 == 0
	*(short*)0 == 0
*BUT*	*(int*)0 == 1041305344  !!!!	(try it...)
*AND*	*(float*)0 == 1.5807e-30

and all bets are off for the case
	((my_struct*)0)->element_in_my_struct

So any pointer chasing code which depends on *0==0 is going to be
highly non-portable at best, and will probably break even on
machines like the VAX.

It is typically code like

	strcmp("something", (char*)0);

which will work on a VAX, but crash on a Sun (or any other machine
which doesn't map in page 0).

There is, as far as I can see no general solution to this problem.
I seem to remember that K&R say (roughly, I don't have it to hand)
that 0 does not correspond to *ANY* valid data.

>So, to restate what I've said so many times (am I getting boring yet?):

Well, quite frankly, this dereferencing NULL business comes up
far too often on the net.

>It would seem that our definitions of "good code" are very different.
>My definition requires that the code do what I said to do. As I've

Just *what* are you saying when you dereference NULL?
Are you saying give me 0 (and if so, how much 0), are you
saying give me whatever random constant garbage happens to
be at address 0, are you saying give me whatever I wrote at
address 0 (and yes, such systems exist, running Unix), or
are you saying `I really feel like a core dump now'???

>One of the problems I think we've had with this entire exchange is
>that it has centered around C. C is not yet standardized, and because
>it was intended to be a systems programming language C has always
>tolerated machine dependent variations in the semantics of some of its
>operators. I believe the variation has been tolerated because it was
>believed to be justified by the resulting increase in speed. I believe

This is exactly what I mean. What's at zero is *UNDEFINED* in C,
and explicitly illegal in many other languages.

>Bob Pendleton @ Evans & Sutherland


-- 
Peter Lamb
uucp:  seismo!mcvax!ethz!prl	eunet: prl@ethz.uucp	Tel:   +411 256 5241
Institute for Integrated Systems
ETH-Zentrum, 8092 Zurich