Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!apple!portal!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Problem with my C program [a few general hints about malloc]
Message-ID: <2913@atari.UUCP>
Date: 25 Apr 91 20:50:24 GMT
References: <1991Apr21.210056.5685@ccu.umanitoba.ca> <1991Apr22.014758.3846@wam.umd.edu> <A1422792342@thelake.mn.org>
Organization: Atari Corp., Sunnyvale CA
Lines: 34

steve@thelake.mn.org (Steve Yelvington) writes:

>[In article <1991Apr22.014758.3846@wam.umd.edu>,
>     dmb@wam.umd.edu (David M. Baggett) writes ... ]

>> If you want to allocate more memory than can be specified in an unsigned int,
>> use calloc.  It takes two parameters which are multiplied together to get
>> the size of the requested block.  To allocate 128K:
>> 
>> 	p = calloc(128, 1024);

In general, this is not a fix.  I have seen allocators which call malloc
from calloc after multiplying the two args together AS INTS, not longs. So
this does you no good at all.  Some compilers work and some don't in this
respect.  You pays your money and you takes your chances.

>You also can use lalloc, which works like the library malloc()
>function except that it requires a long argument. (Be sure to include
>malloc.h when calling any dynamic memory management functions.)

Much better solution, if your library has lalloc. Some have lmalloc, so try
both.  (I forget if the original poster said what compiler/library he was
using.)

>> In general it is VERY WISE to avoid using the bios Malloc and Free and
>> use the malloc, calloc, and free provided with your compiler of
>> choice.

Humph.  TOS 1.4 and upwards have NO PROBLEMS with Malloc that have been
reported to me.

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt