Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!tank!nucsrl!accuvax.nwu.edu!bob
From: bob@accuvax.nwu.edu (Bob Hablutzel)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Re: Legal Tail Patches
Message-ID: <10050076@accuvax.nwu.edu>
Date: 21 Feb 89 00:28:04 GMT
References: <1285@ccnysci.UUCP>
Organization: Northwestern U, Evanston IL, USA
Lines: 28

> It seems to me that the only time a come-from patch is used is to fix a bug
> in the ROM (if the bug was in RAM, we would simply release a totally new
> piece of code).  This means:

> (A) The only traps that would have a come-from patch are ones called by the
> ROM.  If you know (or can convince yourself) that a certain patch is never
> called from the ROM, then it probably can't have a come-from patch.  

> (B) If you patch a trap and find the return address is not in ROM (ie, the
> call was not made from ROM), then it should be safe to JSR to the original
> trap routine.  This is similar to test #1 above, except you don't check to
> see if the return address is in you application, you test to see if it is in
> RAM. 

Lemme jump in here with a question, and a comment...

Are Apple people the only people blessed to do come-from patches? Let us assume,
for the sake of argument, that I have an application which does come-from
patches (very carefully). Am I breaking the rules?

Also, if I am not breaking the rules, I would really appreciate it if Apple
did not tail-patch. (gotcha!) I know of at least one: the _Open patch in MPW,
which seems to be concerned with having too many files open. Why couldn't this
be handled in a subroutine? This is MPW 3.0, btw, which I got with my TML II
upgrade. MPW 2.0.2 is fine. And, hey, if I'm wrong about this I'll happily
eat, er, crow.

Bob Hablutzel	Wildwood Software	BOB@NUACC.ACNS.NWU.EDU