Newsgroups: comp.sys.amiga.programmer
Path: utzoo!utgpu!watserv1!watdragon!rose!ccplumb
From: ccplumb@rose.uwaterloo.ca (Colin Plumb)
Subject: SetFont(rp, &MyFont) eats 24 bytes of fast memory - Found: 2.0 bug
Message-ID: <1991Mar21.044941.15171@watdragon.waterloo.edu>
Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes)
Organization: University of Waterloo
References: <1991Mar20.220218.25195@watdragon.waterloo.edu>
Date: Thu, 21 Mar 1991 04:49:41 GMT
Lines: 32

Well, a bit of poking around in the 2.0 includes discovered the answer.

It's not a message port; it's just that 2.0 usurped the pointer to
point to a TextFontExtension struct.  The includes I have say it's
a 20 byte struct, but I'm losing 24... it might have been extended
since I saw it, or those mysterious GfxFree/GfxNew/GfxAssociate functions
I saw doing some bookkeeping for me, but in any case I don't know how to
free it safely.  More digging, and aha!  There are ExtendFont and
StripFont functions that look significant...

So now my cleanup code, after doing a SetFont() back to the old, saved
rp->Font pointer for paranoia's sake, tests to see if the tf_Extension
(a.k.a. tf_Message.mn_ReplyPort) pointer holds non-NULL, and if so,
calls the 2.0-specific StripFont() function on my TextFont structure.

This seems to work, without memory leakage, on both 1.3 and 2.0.
So, I think I've found an (admittedly minor) backward-compatibility bug
between 2.0 and 1.3.  Perhaps some 2.0-knowledgeable (or at least,
autodoc-posessing!) person could tell me if this ad hoc solution is
indeed correct?

The 1.3 manual mentions the importance of putting the old font back
into the rastport before closing it, so well-behaved code probably does
this already.  Perhaps the same logic which automagically called
ExtendFont() for me could call StripFont() as part of the cleanup.
(The graphics.library seems to need the extension; stuffing the
apropriate values into the RastPort structure produces odd effects in
JAM2 mode...)

Thanks!
-- 
	-Colin
