Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!cornell!uw-beaver!microsoft!w-colinp
From: w-colinp@microsoft.UUCP (Colin Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Unsupported Programming Practices
Message-ID: <215@microsoft.UUCP>
Date: 8 Jan 89 04:47:38 GMT
References: <5605@cbmvax.UUCP> <10227@well.UUCP> <5632@cbmvax.UUCP> <10262@well.UUCP>
Reply-To: w-colinp@microsoft.UUCP (Colin Plumb)
Organization: Microsoft Corp., Redmond WA
Lines: 26


In article <10262@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
->> [In response to "allocating RastPorts on the stack is a Bad Idea]

->	AARRGGHHH!  What a bloody nuisance.  Throwing temproary RastPorts
->around on the stack has been a real nice win for me.  I've been doing things
->like this:
->
->	if (loadILBM() == SUCCESS) {
->		struct RastPort	lrp;
->
->		InitRastPort (&lrp);
->		lrp.BitMap = &loaded_bitmap;
->		ClipBlit (&lrp, 0L, 0L, &dest, 0L, 0L, w, h, MINTERM_COPY);
->	}

->	So now I have to do AllocMem()s with sanity checks with
->corresponding FreeMem()s?  Foo.

No; this usage should be safe.  If you're only making *library* calls using
the stack-allocated RaatPort, the only process that needs the data is
yours, so it can be MEMF_PRIVATE.  You only need MEMF_PUBLIC if passing
the RastPort to Intuition or some such.  But in this case, it's going to
be around for a while, so you probably allocate it anyway.
-- 
	-Colin (uunet!microsof!w-colinp)