Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: XFCN/XCMD string in LSC C v3.0
Summary: Self-modifying code examined.
Keywords: A4-relative data, blessing or curse?
Message-ID: <12970@dartvax.Dartmouth.EDU>
Date: 9 Apr 89 20:54:59 GMT
References: <kYDWlFy00VQE8JCEES@andrew.cmu.edu> <12964@dartvax.Dartmouth.EDU> <28737@ucbvax.BERKELEY.EDU> <12968@dartvax.Dartmouth.EDU> <6944@hoptoad.uucp>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 49

In article <6944@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>In article <12968@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu 
	(Earle R. Horton) writes:
>>     Several problems exist with this approach.  The chief one is
>>writing to the code resource.  This is bad.  It can lead to strange
>>bugs on 68020 machines.
>
>Sorry, Earle, you're generally one of the better informed voices here
>and one well worth reading, but you seem to be having a bad luck streak
>this week.  There would only be a problem if the address where A4 is
>stashed were executed.  That's the only way the address could find
>its way into the instruction cache and cause problems: by being executed.
>Since it's just being handled as data, there's no problem.

>...Stashing data in code space is *not* self-modifying code.

  The second group is code that changes the block that the code is
  stored in.  Keeping variables in the CODE segment itself is an example
  of this.  This is uncommon with high-level languages, but it is easy
  to do in assembly language (using the DC directive).  Variables
  defined in the code itself should be read-only (constants).  Code that
  modifies itself has signed a tacit agreement that says "I'm being
  tricky, if I die, I'll revise it."
  ...
  If you choose to abuse, you also agree to personal visits from the
  Apple thought police, who will be hired as soon as we find out.

     Technical Note 117, "Compatibility: Why and How." Bo3b Johnson.

     Well, Apple thinks that this *is* self-modifying code.  To be
honest, I don't know if this kind of thing gets into the code cache or
not, but it might someday.  If you want to write straight-up code
then writing to logical code blocks is to be avoided.  If you want to
write tricky code, then you may do so.  The best advice seems to be to
avoid being tricky if you want your programs to last.

     Programming the Macintosh is difficult.  Relying on a compiler
which uses questionable tricks to make that task appear easier is
risky at best.  MPW compilers do not implement global read/write
variables for non-application code resources, presumably because Apple
has not found a safe place to stash the base register.

     Conclusion:  Using global variables in non-application code
resources is at present risky business.  Even though the compiler
writer says "Go ahead and do it," the choice to be tricky or not is
yours.
Earle R. Horton

Graduate Student.  Programmer.  God to my cats.