Xref: utzoo comp.sys.ibm.pc:34337 comp.lang.c:21574
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!dogie.macc.wisc.edu!uwvax!umn-d-ub!umn-cs!nis!quad!dts
From: dts@quad.uucp (David T. Sandberg)
Newsgroups: comp.sys.ibm.pc,comp.lang.c
Subject: Re: Microsoft C - Heap space question
Keywords: heap microsoft-c
Message-ID: <259@quad.uucp>
Date: 7 Sep 89 21:38:20 GMT
References: <3631@cbnewsh.ATT.COM> <4143@csd4.csd.uwm.edu> <2930@puff.cs.wisc.edu>
Reply-To: dts@quad.uucp (David T. Sandberg)
Distribution: usa
Organization: Quadric Systems, Richfield MN
Lines: 17

In article <2930@puff.cs.wisc.edu> schaut@rt1.cs.wisc.edu (Richard Schaut) writes:
:In article <4143@csd4.csd.uwm.edu> chad@csd4.csd.uwm.edu (D. Chadwick Gibbons) writes:
:|function is declared--I believe--as "char far *farmalloc(size_t);"  
:				      ^^^^
:If MS C is ANSI compatible, then the function would be declared as
:"void far *farmalloc(size size_t);" thereby removing the need to cast
:the return value to a pointer to a specific kind of object.

MSC 5.1 does indeed return void pointers from all of it's malloc calls.
It should be noted that the referred-to function is actually "void far
*_fmalloc(size_t size);", and that when compiling with large model,
malloc() calls are mapped to _fmalloc by default.

-- 
                                  David Sandberg - Quadric Systems
 "As of Friday, August 25, 1989,  PSEUDO: dts@quad.uucp
      Triton is a Placemat."      ACTUAL: ..uunet!rosevax!sialis!quad!dts