Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!cwlim!trier
From: trier@cwlim.CWRU.EDU (Stephen C. Trier)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: NULL pointer error
Keywords: Null dos error
Message-ID: <1990Jul16.003229.23335@usenet.ins.cwru.edu>
Date: 16 Jul 90 00:32:29 GMT
References: <2008@bnlux0.bnl.gov> <27092@netnews.upenn.edu> <319@taumet.com>
Sender: news@usenet.ins.cwru.edu
Reply-To: trier@po.CWRU.Edu
Organization: Case Western Reserve Univ. Cleveland, Ohio, (USA)
Lines: 27

Debugging a null pointer error is a little simpler than it may seem.  The
most likely two locations to watch are DS:0000 and DS:0008.  The first is
NULL and the second is where a malloc'ed pointer will point if it is
mistakenly typecast to a near pointer.

With Turbo C, the low memory area checked is filled with the Borland
Copyright.  It is checksummed as part of the exit code and the error
message is printed if the checksum is incorrect.

_Any_ write to that area should be considered a bug.

Note that another common cause of null pointer errors is code like the
following:

	int a;
	scanf("%d", a);

"a" will be interpreted as a pointer, causing a random write into memory
corresponding to whatever is in "a" when scanf is called.  If "a" is 0,
you will receive a null pointer error.

-- 
Stephen Trier                              Case Western Reserve University
Home: sct%seldon@scl.cwru.edu              Information Network Services
Work: trier@cwlim.ins.cwru.edu
                 I do _not_ speak for the University.