Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!usc!orion.oac.uci.edu!ucivax!megatek!hollen From: hollen@megatek (Dion Hollenbeck) Newsgroups: comp.os.msdos.programmer Subject: Re: Turbo C's Run Time Error Messages Message-ID: Date: 1 Oct 90 14:51:22 GMT References: <6243@uceng.UC.EDU> Sender: news@megatek.UUCP Organization: Megatek Corporation, San Diego, California Lines: 47 In-reply-to: dsims@uceng.UC.EDU's message of 28 Sep 90 20:46:24 GMT > 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