Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!usc!apple!escher From: escher@Apple.COM (Michael Crawford) Newsgroups: comp.lang.c++,apple.general Subject: Re: Failed allocation in constructors? Message-ID: <9114@goofy.Apple.COM> Date: 12 Jul 90 18:55:21 GMT References: <9075@goofy.Apple.COM> <42825@apple.Apple.COM> <1990Jul11.180345.21464@Solbourne.COM> Organization: Apple Computer Inc., Cupertino, CA Lines: 39 In article <1990Jul11.180345.21464@Solbourne.COM> imp@dancer.solbourne.com writes: >In article <42825@apple.Apple.COM> fair@Apple.COM (Erik E. Fair) writes: >>So, dereferencing zero isn't a bad thing; it's just bad to assume that >>you always can across all possible hardware architectures that your >>program might be run on. > >In most implementations of C and C++ a Nil pointer has all its bits >turned off, but not all implementations do this. Regardless of the >implementation, saying "p=0" will get you a Nil pointer. So if you >then say *p, that is an error. However, according to the standard, >compilers are free to not notify the user this error has occurred. According to me, no system that pretends to have protected memory has any excuse to not map out page 0. This, to me, is like buying a fancy car, and having them leave out the brakes. I understand it is perfectly legal to have it mapped in, as long as address 0 is either never used _or_ (void*)NULL does not have all 0 bits (this is not always the case in practice, as recently discussed in comp.unix.wizards), but I consider segmentation violations and core dumps to be extremely important debugging tools, and would not buy a protected-mode OS that did not do this. Of course the Macintosh doesn't, but it does not claim to have protected memory, and one is not paying for it. I program the mac because I find it aesthetically pleasing, but I also program on Unix (Sun particularly) because I find it easier to get things to work. -- Michael D. Crawford Oddball Enterprises Consulting for Apple Computer Inc. 606 Modesto Avenue escher@apple.com Santa Cruz, CA 95060 Applelink: escher@apple.com@INTERNET# oddball!mike@ucscc.ucsc.edu The opinions expressed here are solely my own. alias make '/bin/make & rn'