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