Null Pointer Assignment

[Bob Rusbasan]

In article <1990Oct16.010142.14499 at inel.gov> cdm at gem-hy.Berkeley.EDU (Dale Cook) writes:
>In article <615 at quad.sialis.mn.org>, dts at quad.sialis.mn.org (David T.
>Sandberg) writes:
>|> In article <15004 at mentor.cc.purdue.edu> schikore at mentor.cc.purdue.edu
>(Dan Schikore) writes:
>|> >What exactly does the run-time error "Null Pointer Assignment" mean?  I get
>|> >this error after a series of recursive calls to a function, but the
>|> >error does not come up until the end of the program.
 
>|> I seem to recall that executables produced by some unnamed DOS compiler
>|> do a check of memory location 0 at the conclusion of their run, and
>|> kicks out this message if the value therein has been changed since the
>|> program was started.  In other words, the assignment to a null pointer
>|> could be occurring anywhere within the program... it is by virtue of
>|> the cleanup checking that you hear about it after the fact.  (Better
>|> then than never, I suppose.)
>|> 
>|> It might help if you mention which compiler you are using.

>I get this error faithfully every time I leave PeachTree accounting 
>software.  Hasn't done any apparent harm, but I don't exactly have
>a warm fuzzy about it, either...

Not even after reading the above?

I replied to the original post thru email, but since it keeps coming
up...

This happens with some (all?) of the DOS compilers, including TC/TC++
and MicroSoft.  As stated above, the compiler has some data at
memory location DS:0000.  If you write to the location pointed to by
a NULL pointer, you corrupt that data.  When the executable is done
running, it checks the data and spits out the message if it has been
changed.

One funny thing is that the actual "NULL pointer assignment" message
is also in the general area, so it often comes out looking rather
strange, at least with TC/TC++.

As far as "better late than never," I wouldn't exactly call it "late."
DOS is slow enough, and I wouldn't want it to be constantly checking
for this throughout the execution of the program.  The compiler would
also have a hard time finding it.  The message usually will come out
every time you run the program, so you know the first time you run it.
At that point you should immediately find the problem and fix it.

I've redirected followups to comp.os.msdos.programmer in case this
thread still refuses to die.

---
Bob Rusbasan
bob at en.ecn.purdue.edu