On Fri, May 7, 2010 at 10:48 AM, Dale Farnsworth <d...@farnsworth.org>wrote:
> kitepilot wrote: > [ some code showing that null pointer dereference on Linux results in > a seg fault, while it just returns 0 on AIX.] > > Yes, that is indeed the way it works. On the PDP-11, where much of > the early (not earliest) UNIX code was written, there was no hardware > support for separate instruction and data mapping. Code was loaded > at virtual address 0. On most machines, a null-pointer dereference > simply loads the contents of address 0. It happened that the first > byte of crt0.o on the PDP-11 had the value 0. So, on the PDP-11, > a null pointer dereference returned 0. This resulted in some applications > dereferencing null pointers and expecting a 0 value and not a seg fault. > When UNIX was ported to other machines, on some a null pointer dereference > would seg fault and on others it would return a non-zero value.[1] Both > of these required additional effort to fix the bug in the original > application code. However, some of these bugs didn't show up until > the applications had shipped. Other bugs were in customer code. In > both cases, customers viewed it as a porting issue. My program didn't > have any problems when I ran it on PDP-11 UNIX, but it breaks when I > recompile it and run it on AIX on your hardware. > > As a result, IBM modified AIX to return a 0 on a null-pointer in order > to be bug-compatible with UNIX on a PDP-11. Other vendors did the > same. On the Motorola 680XX-based systems that I developed UNIX for > during that timeframe, by default, a null pointer reference would > seg fault. However, if an otherwise unused bit was set in the executable > file's header, a null pointer would return 0 as a workaround, so customers > didn't have to debug their broken programs. > > -Dale > > [1] I remember an amusing example in the source code to the cpio program > for System III UNIX, IIRC. The original code had a check for a null > pointer. Instead of doing: > if (p != NULL) > it used > if (*p != '\0') > When that code was ported to another machine, that code no longer worked > and was changed to > if (*p != '\0' && *p != 'G') > and that was the way I found the code. Apparently, on the machine to > which the program had been "ported", a null pointer dereference of a > (char *) would return the character G instead of 0. Yes, I had a good > laugh when I found that one. > --------------------------------------------------- > The stuff of a thousand exploits....NULL Deference pointers. -- Office: (480)307-8707 AT&T: (503)754-4452 Systems Engineer www.ivedaxpress.com
--------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
