Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!haven.umd.edu!wam.umd.edu!dmb
From: dmb@wam.umd.edu (David M. Baggett)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Problem with my C program [a few general hints about malloc]
Message-ID: <1991Apr23.144225.6273@wam.umd.edu>
Date: 23 Apr 91 14:42:25 GMT
References: <1991Apr21.210056.5685@ccu.umanitoba.ca> <1991Apr22.014758.3846@wam.umd.edu> <827@utrcu1.UUCP>
Sender: usenet@wam.umd.edu (USENET Posting)
Organization: University of Maryland at College Park
Lines: 37

In article <827@utrcu1.UUCP> optimiza@utrcu1.UUCP (De Leeuw) writes:
>In article <1991Apr22.014758.3846@wam.umd.edu> dmb@wam.umd.edu (David M. Baggett) writes:
>>
>> [my brain-damaged code]
>>
>Unfortunately, this will not work the way you intend. Assume you want to
>Malloc() a block of 65536 bytes. This leads to hi being 1, and lo being
>0. This will calloc() a block of 1*0=0 bytes. What you want to do is
>factorize size in two factors that are both small enough to be handled
>by calloc. I cannot come up right now with an algorithm that does this
>both time and memory efficient.

Oops, looks like someone broke into my account and posted something stupid!
I'll make sure I use better passwords in the future.  :-)

Actually what I usually do in practice is something like

	calloc((unsigned) (bigsize / 32), 32);

which will work for sizes up to 32*65536 bytes.  You can always increase
the "chunking factor" here at the expense of a few wasted bytes allocated.
This is basically what you describe but "by hand."

Another caveat re: Malloc is that it takes a _long_ parameter:

	Malloc(32L);

instead of

	Malloc(32);	/* <- This will cause bad things to happen */

This type of bug is particularly difficult to track down.  It would be
nice if the os-binding for Malloc had a (long) typecast in it to solve
problems like these -- oh well.

Dave Baggett
dmb%wam.umd.edu@uunet.uu.net