Path: utzoo!attcan!uunet!tektronix!tekgen!tekigm2!phils
From: phils@tekigm2.TEK.COM (Philip E Staub)
Newsgroups: comp.sys.amiga
Subject: Re: manx c
Message-ID: <3839@tekigm2.TEK.COM>
Date: 22 Nov 88 04:56:54 GMT
References: <8811160401.AA24804@postgres.Berkeley.EDU>
Reply-To: phils@tekigm2.TEK.COM (Philip E Staub)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 34

In article <8811160401.AA24804@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
... question about large allocations via calloc ...
>
>	However, at least in 3.6, there is an 'lmalloc' call which takes a
>long (for those of you who use 16 bit ints).  Since this doesn't automatically
>zero the memory, you still have to do that yourself.
>
>						-Matt

The lmalloc() has been around for a long time in the Manx compiler. I'm
quite sure I had it when I bought the 3.20a compiler over 2 years ago. In
addition, even then, malloc() was implemented as follows:

The Manx malloc() call merely extracts the size argument into a long
variable and calls lmalloc(). The size argument is treated as unsigned.
When using 16 bit ints, this means you get no more than 65535 bytes. When 
using 32 bit ints, the same thing happens, meaning that a call on malloc() 
is equivalent to a call on lmalloc(), with the exception that you have an
extra level of subroutine call.

What you may have to be careful about is indexing the pointer you get from 
lmalloc() by a number larger than 65k. I haven't been able to reproduce this
with the 3.6 compiler, but I know that earlier versions had problems doing
this, since the compiler treated the index as an 'int' rather than a long,
even if you used a 'long' variable as the index. Caveat Emptor.

Yes, you still have to clear the memory yourself.

Phil
-- 
------------------------------------------------------------------------------
Phil Staub        
Tektronix, Inc., Vancouver, Washington 98668
phils@tekigm2.MEN.TEK.COM