Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!dewey.soe.berkeley.edu!oster From: oster@dewey.soe.berkeley.edu (David Phillip Oster) Newsgroups: comp.sys.mac.programmer Subject: Re: XFCN/XCMD string in LSC C v3.0 Message-ID: <28737@ucbvax.BERKELEY.EDU> Date: 8 Apr 89 23:45:13 GMT References: <12964@dartvax.Dartmouth.EDU> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) Organization: School of Education, UC-Berkeley Lines: 23 In article <12964@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > Using A4 as a base for global variables is a hack, anyway. There >are situations I know of which will invalidate A4, making your global >variables useless. (Dialog filter procs, for example.) But Earle, that is exactly what the routines SetUpA4() and RestoreA4() fix: The compiler puts the data in the same resource as the code, after the code. The routine RememberA0() stashes away A0, which on entry is a pointer to the resource itself. It staches it in the resource, but you are going to be writing to the data area of the resource anyway, so this is no worse. SetUpA4() saves the old value of A4, and sets A4 to point at the remembered value. After that, you have access to globals until RestoreA4(). Things like dialog filter procs, and other procedures that will be called by the operating system need to use SetUpA4() RestoreA4() to get at the code resource's globals. This is no kludge, this is elegance compared to passing a pointer to a record to every call. One surprise: even if you have no globals, you still need to use SetUpA4() and RestoreA4() to get at string constants and float constants. Now that is a kludge!