djm@castle.ed.ac.uk (D Murphy) (11/12/90)
I have a program compiled under TC 2.0 which executes perfectly except that it generates a Null pointer assignment AFTER the last instruction (as determined by putting a puts() in and getting the error message after the intentonal one). Anyone know why this might be happening ? Murff...
rusbara2@sage.cc.purdue.edu (Bob Rusbasan) (11/13/90)
In article <7129@castle.ed.ac.uk> djm@castle.ed.ac.uk (D Murphy) writes: >I have a program compiled under TC 2.0 which executes perfectly except >that it generates a Null pointer assignment AFTER the last instruction >(as determined by putting a puts() in and getting the error message >after the intentonal one). If this isn't in the faq, could someone put it there? I don't know if this is the same guy, but I've seen this twice today. What happens is after running the program it checks the data at the beginning of it. If it has been corrupted (usually by writing to address 0, or NULL) it gives you the error message. Find where you write to a NULL pointer, and fix it. See comp.lang.c. for a more detailed post (I don't feel like going through all of it twice, and this should suffice for the most part).
Ralf.Brown@B.GP.CS.CMU.EDU (11/13/90)
In article <7129@castle.ed.ac.uk>, djm@castle.ed.ac.uk (D Murphy) wrote: }I have a program compiled under TC 2.0 which executes perfectly except }that it generates a Null pointer assignment AFTER the last instruction }(as determined by putting a puts() in and getting the error message }after the intentonal one). } }Anyone know why this might be happening ? In small-data models (tiny, small, medium), the runtime code contains a special check in the exit code to see whether your program has stored anything through a NULL pointer. If you get the message, it means that your program did not execute perfectly, even though it appeared to do so. If you change to a large data model, you will most likely crash your system when you run the program, because a NULL pointer will then point at the interrupt vector table in low memory. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: 1:129/3.1 Disclaimer? | I was gratified to be able to answer promptly, and I did. What's that? | I said I didn't know. --Mark Twain
np4@prism.gatech.EDU (POMPONIO,NICHOLAS A) (11/13/90)
In article <7129@castle.ed.ac.uk> djm@castle.ed.ac.uk (D Murphy) writes: >I have a program compiled under TC 2.0 which executes perfectly except >that it generates a Null pointer assignment AFTER the last instruction >(as determined by putting a puts() in and getting the error message >after the intentonal one). > >Anyone know why this might be happening ? > >Murff... As I understand it, the TC runtime system checks location 0:0 at exit time to see if it was modified. If so, it prints the warning message. Thus, even though the message occurs at the end of the program, the actual Null pointer assignment could occur any anywhere in the program. -- POMPONIO,NICHOLAS A Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!np4 Internet: np4@prism.gatech.edu
tcs@router.jhuapl.edu (11/14/90)
In article <7129@castle.ed.ac.uk>, djm@castle.ed.ac.uk (D Murphy) writes: >I have a program compiled under TC 2.0 which executes perfectly except >that it generates a Null pointer assignment AFTER the last instruction >(as determined by putting a puts() in and getting the error message >after the intentonal one). > >Anyone know why this might be happening ? > >Murff... Isn't this in the FAQ? Anyway, you are overwriting a memory location. Check your code for pointers that aren't malloc'd. Whenever I get this, it's usually because I created a pointer but didn't assign it to something (by using malloc or = "xxx"). Carl Schelin tcs@router.jhuapl.edu
stever@Octopus.COM (Steve Resnick ) (11/14/90)
In article <16962@hydra.gatech.EDU> np4@prism.gatech.EDU (POMPONIO,NICHOLAS A) writes: [Stuff Deleted] > >As I understand it, the TC runtime system checks location 0:0 at exit time to >see if it was modified. If so, it prints the warning message. Thus, even >though the message occurs at the end of the program, the actual Null pointer >assignment could occur any anywhere in the program. This is not entirely true. BTW - THIS IS IN THE FAQ LIST. I make mention that this isn't true since playing with things at address 0:0 could be real painful. The NULL pointer assignement comes from the C runtime (on TC, in C0?.OBJ) in memory models which use 16bit pointers (relative to DS). When the program writes data to a NULL pointer in these models, the C runtime warns of this at the termination of the program. If you are using 32bit pointers, writing data to NULL will overwrite the interrupt vector table. This is an important consideration if you are doing modeling in small model and then moving to a larger memory model when doing your "production" code. Hope this helps.... Steve -- ---------------------------------------------------------------------------- steve.resnick@f105.n143.z1.FIDONET.ORG - or - apple!camphq!105!steve.resnick Flames, grammar errors, spelling errrors >/dev/nul The Asylum OS/2 BBS - (408)263-8017 IFNA 1:143/105.0
jagrogan@vax1.tcd.ie (11/14/90)
> I have a program compiled under TC 2.0 which executes perfectly except > that it generates a Null pointer assignment AFTER the last instruction > (as determined by putting a puts() in and getting the error message > after the intentonal one). I used to get that error with TC2.0 as well. I can't exactly say how I got rid of it, but I found that by using full ANSI C, the problem disappeared. I think it has something to do with declaring main() as void main() or whatever it returns. Hope this helps. John Grogan. -- ------------------------------------------------------------------------------------- jagrogan%vax1.tcd.ie@cornellc.cit.cornell.edu jagrogan%vax1.tcd.ie@pucc.princeton.edu 3rd Year Computer Science jagrogan@vax1.tcd.ie@cunyvm.cuny.edu Trinity College Dublin. jagrogan@vax1.tcd.ie jagrogan@unix1.tcd.ie uunet!vax1.tcd.ie!JAGROGAN@uunet.uu.net ------------------------------------------------------------------------------------- "I haven't lost my mind.....I'm sure it's backed up here somewhere!"