On Fri, May 7, 2010 at 10:48 AM, Dale Farnsworth <dale@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