Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdahl!dgcad!gary From: gary@dgcad.SV.DG.COM (Gary Bridgewater) Newsgroups: comp.lang.c++ Subject: Re: references to dereferenced null pointers, etc... Message-ID: <1457@proa.SV.DG.COM> Date: 16 Mar 90 06:43:41 GMT References: <51083@microsoft.UUCP> <25EB8EE8.8462@paris.ics.uci.edu> <1990Mar12.175613.12082@utzoo.uucp> <1623@argus.UUCP> Reply-To: gary@proa.SV.DG.COM Organization: Data General SDD, Sunnyvale, CA Lines: 21 In article pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes: >If I remember correctly, either the Pr1me or Data General C did >represent the null pointer with a bit pattern that was not all 0s. The DG MV series has ring structured memory addresses (for all you MULTICS fans) in which the second, third and fourth bits of a (16 bit) word address or the first three bits of a byte address encoded the ring number (user ring 4-7). So the address of the zeroth word in the user default ring (7) would be 0x70000000 and the address of the zeroth byte would be 0xE0000000. HOWEVER, NULL is still defined as 0. Note that this has the (optional adjective) side effect of causing dereferences of NULL addresses to trap. Amazing how much existing (running?) code would core dump when ported to an MV for just this reason. (This is NOT a VAX.) Please don't remember us as a company with funny NULLs. (We did port C++ to it - not to completly ignore the group subject.) -- Gary Bridgewater, Data General Corporation, Sunnyvale California gary@sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary The impossible we understand right away - the obvious takes a little longer.