Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!vsi1!octopus!stever
From: stever@Octopus.COM (Steve Resnick )
Newsgroups: comp.os.msdos.programmer
Subject: Re: TC 2.0 odd behaviour, me or it ?
Message-ID: <1990Nov13.180900.17455@Octopus.COM>
Date: 13 Nov 90 18:09:00 GMT
References: <7129@castle.ed.ac.uk> <16962@hydra.gatech.EDU>
Reply-To: stever@octopus.UUCP (Steve Resnick )
Organization: Octopus Enterprises, Cupertino CA
Lines: 27

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