🚀 go-pugleaf

In article <2008@bnlux0.bnl.gov>, reilly@bnlux0.bnl.gov (kevin reilly) writes:
|> After exiting my program DOS writes an error to the screen
|> NULL pointer error R6001
|> I understand the meaning of the error message but how do I go about
|> debugging the program to find what is causing it.
|> From reading the documentation from MicroSoft (QC2.5) the program will
|> compile and link error free. But when run and then exited that is when
|> the error will appear.
|> The program ran error free up until I linked in the menu.obj file that
|> came with the compiler.
|> I guess the question is: What memory address do I watch when stepping
|> through the program?
|> Thank you in advance!
|> reilly@bnlux0.bnl.gov

What I have done in my Microsoft C programs to help find such problems is to
add the following line at the end of each routine:

assert(_nullcheck());

If you don't want the assertion there in released code, put a #ifdef around it.
This line will call the Microsoft runtime routine to check the section of
memory everyone's been describing here and tell you the file and line number
when it does occur.

Just pointing a finger at the offending routine is usually enough to elicit an
"Oh yea!  Boy was that stupid!" (at least for me).

Wayne Geiser
Apollo Computer, Inc. - A subsidiary of Hewlett Packard
geiser@apollo.hp.com

"The holy passion of Friendship is of so sweet and steady and loyal and
 enduring a nature that it will last through a whole lifetime - if not
 asked to lend money."

    - Mark Twain.