7 May
2005
7 May
'05
3:18 p.m.
On 5/7/05, John Foust <jfoust at threedee.com> wrote:
I'm not remembering this sort of malloc() bug.
Are you thinking
of something with the AmigaDOS AllocMem()/FreeMem() calls? Or something
in a particular C compiler's library? I can see how a particularly
poorly written C application that never checked malloc()'s return
value could crash if it wrote to a null pointer.
Back in the days of AmigaDOS 1.0 (and probably 1.1), you never saw it.
AllocMem() used to return a valid pointer or wouldn't return at all.
Programmers got lazy and never checked for valid pointers because they
were defacto valid.
A poorly written C program will crash the OS because just past
0x0000000 is 0x00000004, called 'ExecBase', which is, if you remember,
where the OS stores the master pointer to find libraries, the Exec,
and pretty much everything that follows. Make a write to absolute
location 4 and the entire machine blows up spectacularly. Later
machines (with MMUs) were able to protect the lowest page of memory,
but that wasn't possible with a plain-old 68000.
Also, 0x00000000 was not guaranteed to contain 0x0000... it usually
did, but it wasn't an OS requirement. Many programmers who confused a
null pointer with a pointer to a null got bit later, when things
changed (which is why the program Enforcer exists now).
What will be humbling is that when we find the answer,
we will
find it in an article that I wrote in the 80s. :-) I've been meaning
to put all my old Amazing Computing articles online.
Heh... that might be. Can't wait to see that stuff online.
-ethan