🚀 go-pugleaf

In article <1990Sep30.210345.1361@isis.cs.du.edu> canderso@isis.UUCP (Chuck Anderson) writes:
>In article <6243@uceng.UC.EDU> dsims@uceng.UC.EDU (david l sims) writes:
>
>>error messages. One particularly annoying message says at the end
>>of the program, "null pointer assignment." I have no idea where
>>I assigned some value to a null pointer, and even if I did, it doesn't
>>seem to effect my programs. I don't like this statement coming up
>>at the end of my program. Is there any way to turn run time error
>>messages off? 
>
>OUCH!! This one's gonna' bite you in the arse eventually. You're program is
>doing a wild write into memory. Change the environment and you could see some
>nasty *a*ffects.
>
>> Does TC give any assistance in tracking down this error.
>
>Well, do you have the debugger? I had this problem... once :^) and when I ran
>the debugger the environment was changed enough that the affect of this "null
>pointer" was quite obvious.
>
>Don't let this ride. It is something that you need to find!
>
This is something in the FAQ list posted monthly. The "null pointer assignment"
message comes from the tiny, small (and probably medium) memory model runtime.
What happens, is that NULL points to DS:0. The data there is checksum'd. If 
the checksum doesn't match, the runtime assumes you have assigned a value to 
a NULL pointer. Watching DS:0 - DS:10 will most likely show you your error.
Note, that if this were compact, large or huge memory model, you would not
get this message and end up trashing your interrupt vector table instead since
NULL in those models points to 0:0. 

Hope this helps and sorry (for you other netlanders) for wasting bandwith on
a FAQ.

Steve

-- 
----------------------------------------------------------------------------
steve.resnick@f105.n143.z1.FIDONET.ORG - or - apple!camphq!105!steve.resnick
Flames, grammar errors, spelling errrors >/dev/nul
----------------------------------------------------------------------------