Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!ames!xanth!nic.MR.NET!umn-cs!uf!brant
From: brant@uf.msc.umn.edu (Gary Brant)
Newsgroups: comp.sys.amiga.tech
Subject: Re: ReallocMem
Message-ID: <11848@umn-cs.CS.UMN.EDU>
Date: 1 Apr 89 17:41:29 GMT
References: <6406@cbmvax.UUCP> <DEVEN.89Mar30052014@daniel.pawl.rpi.edu> <6464@cbmvax.UUCP> <DEVEN.89Mar31025148@daniel.pawl.rpi.edu> <432@antares.UUCP>
Sender: news@umn-cs.CS.UMN.EDU
Reply-To: brant@uf.msc.umn.edu (Gary Brant)
Organization: Minnesota Supercomputer Center, Inc.
Lines: 29

In article <432@antares.UUCP> jms@antares.UUCP (Joe Smith) writes:
>In article <DEVEN.89Mar31025148@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes:
>>...  Now, if C-A will add a ReallocMem to Exec V1.4+, it won't be a problem.
>
>I don't understand how ReallocMem could ever work under AmigaDOS unless the
>caller always does a Forbid before the FreeMem and a Permit after the
>ReallocMem.  As soon as you free memory on the Amiga, some other task may get

You're missing the point; if you FreeMem first, you don't even need ReAllocMem.
ReAllocMem should take a pointer to a block and a new size and return a block
of the requested size.  If a new block is needed, ReAllocMem copies the
contents of the old block to the new one before releasing the old block to
the free storage pool.  I don't see why any Forbid/Permit's would be needed
here.


[ rest of atticle deleted ]

>-- 
>Joe Smith (408)922-6220 | jms@antares.Tymnet.COM or jms@opus.Tymnet.COM
>McDonnell Douglas FSCO  | UUCP: ...!{ames,pyramid}!oliveb!tymix!antares!jms
>PO Box 49019, MS-D21    | PDP-10:JMS@F74.Tymnet.COM  CA license plate:"POPJ P,"
>San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"


-Gary Brant		ARPA:	brant@uf.msc.umn.edu


My employer has no knowledge of my ravings.