Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!ucbcad!ucbvax!ucsfcgl!cgl.ucsf.edu!kneller
From: kneller@cgl.ucsf.edu (Don Kneller)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Microsoft C 4.0 large models
Message-ID: <10334@cgl.ucsf.EDU>
Date: Wed, 5-Aug-87 15:26:00 EDT
Article-I.D.: cgl.10334
Posted: Wed Aug  5 15:26:00 1987
Date-Received: Sat, 8-Aug-87 04:40:25 EDT
References: <1112@lznv.ATT.COM> <399@aucs.UUCP> <3225@cucca.columbia.edu> <880@bdmrrr.bdm.com>
Sender: daemon@cgl.ucsf.edu
Reply-To: kneller@socrates.ucsf.edu.UUCP (Don Kneller)
Organization: UCSF Computer Graphics Lab
Lines: 31

In article <880@bdmrrr.bdm.com> davis@bdmrrr.bdm.com (Arthur Davis x4675) writes:
>If you have moved your code to a large model, I hope you have changed
>your malloc calls to _fmalloc (and free to _ffree).  You can get some
>strange results using malloc in a far environment.  One result you won't
>get is the compiler message "Oh gosh, you really shouldn't use malloc in
>a large model".  Not to start an argument with anyone, but it is for
>reasons such as these that I love 68000-family architectures.  Good luck.

Is this true?  I've never had a problem with malloc in large model
programs.  My understanding is _fmalloc is to be called from small
model programs if you want to use far pointers to access more memory
than you would normally be allowed (ie, more than 64K).  In large
model programs, all pointers are far by default.  My experience is
you can use malloc in either model with impunity.

The use of _fmalloc is only necessary in mixed model programming.
You don't have to venture into mixed model programming if you don't
want to.  With proper coding practices (as in, not assuming pointers
and ints are equivalent), the details of large versus small model
programming is handled by the compiler and libraries.

Please be more specific than "you can get some strange results".  This
is not very useful.

Don

-----
	Don Kneller
UUCP:	...ucbvax!ucsfcgl!kneller
ARPA:	kneller@cgl.ucsf.edu
BITNET:	kneller@ucsfcgl.BITNET