Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!decwrl!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Standard File and Desk Accessories
Message-ID: <7597@hoptoad.uucp>
Date: 8 Jun 89 22:09:38 GMT
References: <50967@tut.cis.ohio-state.edu> <7547@hoptoad.uucp> <4972@umd5.umd.edu> <51276@tut.cis.ohio-state.edu> <2015@husc6.harvard.edu> <1241@speedy.mcnc.org>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 75

In article <1241@speedy.mcnc.org> kk@mcnc.org.UUCP (Krzysztof Kozminski) writes:
>>An alternate solution involves some assembly language, and works something like
>>this:
>>	Define a 4-byte spot in your code where you can store a handle.
>
>Yeeechh.  A "spot in your code"? Tim Maroney also suggested writing into
>the code space ... Is self-modifying code OK nowadays?

No, which is fine, since this is not self-modifying code.  No
instructions are being written.  Writing to a DC.L in your code is not
in any way self-modifying code unless the PC hits that location at some
point.  Nothing that's being written is ever executed, that is, no code
is modified.

(Actually some self-modifying code is OK -- the jump tables used by the
Segment Loader are an example.  The modification is very simple and
well-defined: a LoadSeg trap is replaced by a JMP instruction.  The
superstition against self-modifying code originates in more complicated
self-modifying software, which is like Dijkstra spaghetti after you run
it through a blender.)

>Anyway, I have this
>impression that a spot in memory, the address of which is known to more
>than one routine, is called a global variable ...

Then you have a mistaken impression.  A global variable on the Macintosh
is an offset from register A5 or register A4.  The kind of storage Rich
and I are suggesting is an offset from the PC.

>It seems to me that what Rich wrote is essentially equivalent to the following:
>
>	Handle HStorage;
>	SaveAway(h) Handle h;   { HStorage = h; }
>	GetBack(hp) Handle *hp; { *hp = Hstorage; }
>
>That's *not* the answer to the original question (no globals, remember?).

You're being silly, Krsysztof.  They are not equivalent.  For your code
to run on the Mac, there has to be a properly initialized globals
register, which is what Tom can't cope with from MPW C in a DA.  For
the code Rich gave (similar to code myself and others have frequently
used in our trap patches etc.) there is no such requirement.  Tom
didn't object to globals on metaphysical grounds, but on pragmatic
ones.  This is a technical programming problem, not a brain teaser
from a puzzle book.

>Perhaps this modification would work:
>
>	SaveAndGetBack(saveIt, hp)
>	Boolean saveIt; Handle *hp;
>	{ static Handle HStorage;
>	  if (saveIt) HStorage = *hp;
>	  else *hp = HStorage;
>	}
>
>but then, if a development system does not allow globals, then why would it
>allow static variables?

It won't.  This code also requires a globals register, unlike Rich's.
I can't see why you think there might be a difference.

I should point out that the SetUpA4 (etc.) macros in Lightspeed C
actually work by a code-space write.  They can be expected to break on
a memory-protected OS, as can the code-space write Rich and I
proposed.  So when there's an alternative, as there is for what Tom is
trying to do, it should be taken.  (No use enumerating the alternatives
once again.)  Nonetheless, in situations where nothing else will do,
then the code-space write technique is legitimate.
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"The pride of the peacock is the glory of God.
 The lust of the goat is the bounty of God.
 The wrath of the lion is the wisdom of God.
 The nakedness of woman is the work of God."
    - Blake, "The Marriage of Heaven and Hell"