a186@mindlink.UUCP (Harvey Taylor) (11/19/89)
You may recall I posted a question here a while ago asking about
messing with input events. I didn't get any answers so I decided to
test (simply by using it) it for myself.
I modified MiddleButton by Michael Sinz. Basically what my code
does is install an input handler which changes MiddleMouseButtons to
LAmiga-M's. It worked fine, but I was getting $81000005:xxx Gurus;
that is Corrupt Memory List. This struck me as rather odd. After
writing a utility to print the IV lists and finding out that the
input.device maintains its own semi-private list [see xoper_2
source], I looked at the code I had not modified & discovered:
*
************************************************************************
*
* We now allocate and copy the handler...
*
move.l #CodeSize,d0 ; Size of memory
move.l d0,d6 ; Save it...
move.l #MEMF_PUBLIC,d1 ; Type of memory
CALLSYS AllocMem ; Get the memory
move.l d0,a5 ; Save it...
tst.l d0 ; Check it...
beq.s NormalExit ; No memory, no copy...
move.l d0,a1 ; Destination...
lea StartOfCode(pc),a0 ; Source
CopyLoop: move.b (a0)+,(a1)+ ; Copy it...
dbra d6,CopyLoop ; All of it...
*
************************************************************************
*
This section of code allocates N bytes & copies N+1. One way
you can correct this is to insert:
subq.w #1,d6 ; correct for dbra
just before CopyLoop.
Anybody else who is using MiddleButton, might wish to modify their
version, if they're getting gurus.
As for my modification, since changing the code above, I have not
had any unexplained Gurus...
Which I guess does raise the question of what is an adequate testing
procedure for such code.
<-Harvey
"It is dangerous to be sincere, unless you are also stupid." -GB Shaw
Harvey Taylor Meta Media Productions
uunet!van-bc!rsoft!mindlink!Harvey_Taylor
a186@mindlink.UUCP