Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!sics.se!fuug!funic!nntp.hut.fi!nntp!iisakkil From: iisakkil@vipunen.hut.fi (Mika R Iisakkila) Newsgroups: comp.os.msdos.programmer Subject: Re: Memory Models in TC2.0 Message-ID: Date: 7 Jun 91 16:07:12 GMT References: <16856@helios.TAMU.EDU> <4660001@pollux.svale.hp.com> <1991Jun6.164518.20769@borland.com> <1991Jun6.182748.27627@hubcap.clemson.edu> Sender: usenet@nntp.hut.fi (Usenet pseudouser id) Organization: Otaniemi Underground Broadcasting System Lines: 19 In-Reply-To: grimlok@hubcap.clemson.edu's message of 6 Jun 91 18:27:48 GMT Nntp-Posting-Host: vipunen.hut.fi grimlok@hubcap.clemson.edu (Mike Percy) writes: > Sorry. In large data memory models, malloc() is still not identical to > farmalloc(). Guess what the Borland malloc (TC2.0) does in large data models? "return farmalloc((unsigned long) nbytes)" (believe me, I have the source). So your large data model programs would be a bit faster, if you used farmalloc() instead of malloc(). But as you said, they are not interchangable because the argument of malloc() is an int and the argument of farmalloc() is long. > As I said before, it's not really a good idea to explicitly define > pointers as far/near unless you absolutely must (and know what you're > doing). Leaving modifiers off is safe, provided all modules are > compiled under the same memory model. Very true - and it is very important to include all the necessary prototypes, as this example shows us.