Path: utzoo!mnetor!uunet!portal!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: fsel_input, FILEFIX.ACC bug, and Malloc
Message-ID: <1017@atari.UUCP>
Date: 16 Mar 88 18:19:47 GMT
References: <194@actisb.UUCP>
Organization: Atari Corp., Sunnyvale CA
Lines: 29

From article <194@actisb.UUCP>, by federico@actisb.UUCP (Federico Heinz):

> [Malloc question]

For something like a file selector, which will be allocated, do its
thing, then be freed, you should use Malloc(-1L) to find out how much
memory is available, allocate all but (perhaps) 8K of it, then free that
when you're done.  This kind of Malloc-then-free will not screw up the
allocator.  What crashes your system is when you allocate a bunch of
blocks, then free them IN A DIFFERENT ORDER so they don't coalesce
nicely. 

(Well, for that matter, allocating a bunch of blocks can get you in
trouble on its own...)

The reason I say Malloc(-1L) minus 8K is that you still want to have
room for AES to do its thing, and I'm not sure when AES does its
allocation.  It could be that it doesn't do any more after your initial
app_init and do_menu calls. 

THERE IS A BUG IN THE NEW-FILE-SELECTOR ACCESSORY which was posted here. 
The bug is that it doesn't handle trap #2 when D0=0.  This is the old
CP/M-68K way to terminate a process, and the current AES correctly
handles it.  What you should do when you get trap #2 with D0=0 is
Pterm0(). 

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