Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!think.com!hsdndev!husc6!endor!siegel From: siegel@endor.uucp (Rich Siegel) Newsgroups: comp.sys.mac.programmer Subject: Re: malloc() in Think C programming on the Mac Message-ID: <5498@husc6.harvard.edu> Date: 28 Jan 91 03:14:30 GMT References: <1991Jan24.060336.12684@nlm.nih.gov> <4978@awdprime.UUCP> Sender: news@husc6.harvard.edu Reply-To: siegel@endor.UUCP (Rich Siegel) Distribution: comp Organization: Symantec Language Products Group Lines: 39 In article adiseker@ADS.COM (Andrew Diseker) writes: >In article <4978@awdprime.UUCP> eswu@ub.cc.umich.edu writes: >> >>[In article 12426, werner@bio.NLM.NIH.GOV (Craig Werner) >> asks why he gets NULL when he calls malloc() in THINK C.] >> >>The problem lies in the THINK C libraries. In their >>implementation of malloc, they have an if-test to see >>if you are allocating more than 16K of memory. If so, >>it just returns NULL with no check of available system >>resources. [Pretty arbitrary. Also, this restriction is >>not mentioned in their docs. Fortunately, they supply >>source code to their libraries.] >> >> You're confusing the compare against "maxSize" with the compare against "MAXSIZ". "maxSize" is a Memory Manager constant (defined in ): #define maxSize 0x80000000 The storage allocator manages its heap in chunks of 15000 bytes, and any request larger than a chunk will be managed directly via the Memory Manager. If malloc() is returning NIL, it may have been incorrectly prototyped (or not prototyped at all), or the argument may have been specified incorrectly; if the argument to malloc() is the result of an integer multiplication, one of the operands should be cast to (long) to avoid integer overflow. R. Rich Siegel Symantec Languages Group Internet: siegel@endor.harvard.edu "...she's dressed in yellow, she says 'Hello, come sit next to me, you fine fellow..."