Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uwm.edu!ogicse!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re: Problem with X11R4 server `ghosting' on a 68k box.
Message-ID: <9103181109.AA08129@lightning.McRCIM.McGill.EDU>
Date: 18 Mar 91 11:09:46 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 34

> The problem turned out to be in server/ddx/mi/miregion.c.   I don't
> know if this was fixed in later versions but I doubt it because the
> problem was also a problem with bcopy() from libc on this machine.

>             bcopy((char *)REGION_BOXPTR(dstrgn), (char *)new,
>					dnumRects * sizeof(BoxRec));

> [...] when bcopy() is called, both REGION_PTR(dstrgn) and new point
> to the same buffer, but new is a higher address (new =
> REGION_PTR(dstrgn) + numRects).

> This is the only piece of code I could find in the MIT X source in
> which it is assumed that bcopy can handle overlapping buffers.  On
> some machines, perhaps yours, bcopy always copies in the forward
> direction which will overwrite one or more rectangles in the region.

In the absence of a "standard" spec for bcopy(), one has to treat some
implementation as a reference implementation.  Since bcopy() is a
Berkelyism, the implementation to choose would be Berkeley's.  And the
ability to correctly handle overlapping arguments is one of the big
features of Berkeley's bcopy().

Thus, I would maintain that a bcopy() that doesn't correctly handle
overlapping arguments is simply broken.

(Not a very helpful point of view if you're stuck with such a bcopy().
But let's lay the blame where it belongs.  X should perhaps use
memcpy() or memmove(), as appropriate, instead of bcopy(), if such
bcopy() implementations are excessively common.)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu