Sharath wrote: > > ... and found NULL to be defined in stddef.h on my Linux > installation. > > Alright now we can change the value of NULL and if we > did, and if as you said the pointer was converted to a > null_pointer, it should also get the new value of NULL > that we have defined. > > --- [snip] --- > > here we have the definitions for the NULL pointer > being used. Hence, the outputs of printf should change > based on what NULL is defined (if your argument > holds). Execute this program and the value of the > start and end do not change even though NULL is > redefined as some other value. This essentially means > that the conversion to null_pointer does not happen. Hi, I have experience with a platform with a non-zero NULL. It was old stuff. Microsoft C version 4 on an 80286 with "large memory model". On this environment, weird NULL pointer stuff happened behind the scenes. On the 80286 hardware, there was no escape from a segment:offset type of address, so pointers to data entities always had 16 upper bits of data segment address that was assigned by the linker/loader, and 16 lower bits of offset into the program's data segment. A NULL pointer had upper 16 bits of data segment address and lower 16 bits of zero. Really ugly. The compiler did conversions unspecified by the source code to try to guarantee that a null pointer would compare equal to "0". Assignment of "0" to a pointer or use of "0" as an initializer for a pointer were supported and would generate the weird DSEG:0000 null pointer value. As long as the zero was a constant expression, it worked fine. If the zero was inside a variable, the compiler generated extra code to check for the zero special case. It had some bugs and did not always do this correctly. It did help if we cast the 0 as (char *), there was no void type, to hint that we wanted the compiler to generate weird code. If a pointer, null or otherwise, was cast as a long, the segment address in the upper bits was visible. Assignment of a null pointer to a long integer produced a non-zero value. Our NULL symbol in the standard header files was still defined as "0". After a few months, to preserve what little sanity we had left, we defined a second symbol, NULLP as (char *)0. My point is that you cannot simulate this rather bizarre behavior by just defining a non-zero value for the NULL symbol. It will not give the same results as an ugly system where the upper half of the pointer values being manipulated are partially hidden by the compiler. ouch... bad memories. :-P Regards, Ed ---------------------------------------------------------------- Ed Vance edv@macrolink.com Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807 ---------------------------------------------------------------- -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
