Let's define our own NULL

Guy Harris guy at gorodish.Sun.COM
Wed Jun 29 05:22:32 AEST 1988


> 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).



More information about the Comp.lang.c mailing list