Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!gorodish!guy From: guy@gorodish.Sun.COM (Guy Harris) Newsgroups: comp.lang.c Subject: Re: Let's define our own NULL Message-ID: <58258@sun.uucp> Date: 28 Jun 88 19:22:32 GMT References: <160@navtech.uucp> <11326@steinmetz.ge.com> <323@marob.MASA.COM> Sender: news@sun.uucp Lines: 23 > Here, here! You can not image the volumes of code I've had to modify when > porting programs from larger machines to the 80x86 family. Most ends up > with a basic one-line fix: > > if (ptr==NULL) > return(error_value); > > Sure, its an easy fix, but making a large program just to find out I get > a "segmentation violation" (or whatever) and core dump is a real pain. Is this intended to say something about "larger machines" or various memory models? If so, I fail to see what it is; if the one-line fix is adding the "if (ptr == NULL)", this would appear to be required *not* by the representation of null pointers and the "int" value 0 being different on 80x86 C implementations with 16-bit "int"s, but by the fact that while *some* operating systems on *some* "large machines" *currently* allow you to dereference null pointers without getting a core dump, various PC C implementations and OSes don't. Other "large machines" and other operating systems for at least one of the first class of "large machine" do not allow this, and future versions of some members of the first class of operating systems may disallow it as well (other members can be told to disallow it, but they don't do so by default).