Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!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: Integer Size problem
Message-ID: <30836@ucbvax.BERKELEY.EDU>
Date: 23 Aug 89 06:45:01 GMT
References: <15141@dartvax.Dartmouth.EDU> <8362@hoptoad.uucp>
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 32

In article <8362@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>In article <15141@dartvax.Dartmouth.EDU> xxiaoye@eleazar.dartmouth.edu
>(Xiaoxia Ye) writes:
>>Well, eventually, I gave up and wrote a little routine to copy the bytes
>>myself (actually the THINK C inline assembly would do the job).

>If I were doing this, what I'd do would be a lot simpler:

>BlockMove(&myRect, *myHandle, sizeof(Rect));

Xiaoxia Ye descends to assembly language and Tim calls a system call
to do the what should be written as clear, concise C:

	** (Rect **) myHandle = myRect;

One advantage over the call to BlockMove: BlockMove is an operating system
trap, not a tool trap. That means that C gets at it through a glue
routine. If that glue routine is in a not yet t loaded segment (unlikely
but possible) then a heap shuffle may occur during the LoadSeg to bring it
in. myHandle my point to garbage by the time BlockMove gets there.

To say nothing of the fact that the C routine compiles to about 4
instructions (load up two address registers and do to MOVE.Ls)

--- David Phillip Oster      7 line signature follows
Keith Sproul, head of microcomputer support at Union Carbide, NJ, complained
about the poorly digitized fellatio on an IBM porno program. "Mac is better
on everything, and this is no execption."  -- "Computer Porn at the Office"
by Reese Erlich, _This_World_, S.F. Chronicle, p.8, Aug 13, 1989

Arpa: oster@dewey.soe.berkeley.edu
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu