Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!ncar!gatech!hubcap!grimlok
From: grimlok@hubcap.clemson.edu (Mike Percy)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Memory Models in TC2.0
Message-ID: <1991Jun6.182748.27627@hubcap.clemson.edu>
Date: 6 Jun 91 18:27:48 GMT
References: <16856@helios.TAMU.EDU> <4660001@pollux.svale.hp.com> <1991Jun6.164518.20769@borland.com>
Organization: Clemson University
Lines: 47

alexande@borland.com (Mark Alexander) writes:

>In article <4660001@pollux.svale.hp.com> kevino@pollux.svale.hp.com (Kevin Owen) writes:
>>I went through this same problem and found that the secret was to change 
>>all calls to "malloc()" to "farmalloc()".  It appears that compiling in
>>the compact and large models automagically sets all of your data types to
>>"far" but does not change the values that functions return.

>There are couple of mistakes here.

>1. You should not have to use farmalloc() instead of malloc() --
>farmalloc() is identical to malloc() in large data models.  Nor should
>you have change all your pointer variables to far (as an earlier
>posting suggested).
 
Sorry.  In large data memory models, malloc() is still not identical to
farmalloc().  
  To wit, the prototypes (less _cdecl and the like) are
    void * malloc(size_t size);
    void far *farmalloc(unsigned long size);

In large data memory models, both do return far pointers, since malloc
has no specifier, it default to near in small data models and far in
large data models.  But malloc still can only allocate < 64K of data.
It's try that both are taking memory from the far heap -- in fact, after
casting from size_t to unsigned long, malloc calls farmalloc (in large
data meory models).  But they are _not_ identical.
 
And unless you really know what's going to be what, don't mess around
with declaring functions or data pointers far or near. Doing this and
then changing memory models is a sure way to break code. 

>2. Pointer variables, pointers returned by functions, and pointers
>passed to functions will automatically become far pointers in large
>data models, unless you explicitly make them near.

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.

>Perhaps the problem was that the program did not include <stdlib.h> or
>otherwise include a prototype for malloc().  Or perhaps the wrong
>run-time library was being linked.
 
far*alloc functions are defined in <alloc.h>