🚀 go-pugleaf

> I haven't been able to figure out how to control Turbo C's run time
> 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? Does TC give any assistance in tracking down this error
> message?

Other posters have mentioned that this is because you either
1)  changed the copyright message or
2)  wrote to the environment.

They are both somewhat accurate.  The exact cause of this message is
beause you changed the value of one of the bytes in the first 32H bytes
of the data segment  (DS:0 through DS:31).  It just so happens that
the BORLAND copyright message is there, the checking code does not really
care that you changed the copyright message, it is specifically
warning you that you screwed up badly somewhere in your program and
used a NULL pointer.  In the strictest definition, you would have
changed the byte, word or longword at DS:0, bur BORLAND checks for
the first 32H bytes.  

Both previous posters are correct, you MUST track this down.  You do not
know what other side effects you are causing.  The way to track it down
is to open up a window to watch memory and place it so it sees DS:0.
Step through your program in large chunks until you find the chunk
after which any byte down there  has been changed.  Keep dividing and
re-checking until you have it down to a few lines of code.  Then
go back and set a breakpoint just before this section.  Now, ask to
watch the area of memory at DS:0.  Tell TD to continue.  Go make a
cup of tea and relax, this will take a while.  The debugger will stop
at the exact line of code which writes to the "NULL POINTER" area.
Now all you need to do is figure how the pointer you are using there
go messed up.  

You may want to eliminate the divide and conquer portion I suggest,
but I would advise against it.  When I tried to to this the first
time, a program which displayed its sign on screen in less than 2
seconds took over 2 hours to display it.  The reason is that TD
stores a copy of the area you wish to watch.  After every machine
instruction, it stops and compares the stored memory with the actual
memory.  You really don't want to do this.
--
	Dion Hollenbeck             (619) 455-5590 x2814
	Megatek Corporation, 9645 Scranton Road, San Diego, CA  92121
        uunet!megatek!hollen       or  hollen@megatek.uucp