Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.windows.x
Subject: Re: bug in XCopyArea() of X11R3 Xsun server
Keywords: X11R3, Xsun, bw2, SUN4
Message-ID: <1651@auspex.auspex.com>
Date: 18 May 89 18:19:05 GMT
References: <7438@spool.cs.wisc.edu> <341@torch.UUCP>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 33

>On the sparc, x >> y == x >> (y % 32)  !!!! (think about it)
>Thus 0xFFFFFFFF >> 32 == 0xFFFFFFFF.
>
>This means that when the masks are generated and you need to shift by
> >= 32 bits, you don't get what you expected.
>
>Other machines do the expected (to the people who wrote mfbbitblt.c) 
>and put 0x0 in the result.

A*hem*.  *Some* other machines do the expected, others don't.  SPARC is
*not* unique here.  The Intel 80386, as well as, I think, AT&T's 3B20
and their WE32K microprocessors, take the shift count modulo 32.

>I don't particularly want to create a religious war as to whether a strictly 
>out of range value such as 32 should have the results defined or not,

Good idea, since one very common processor - the 386 - does it one way
(the way you don't want it done), and other very common processors do it
differently; that's why the C standard leaves it undefined.

>Unfortunately  we don't have the original source before we put all our 
>speedups in, so I can't give a proper patch file.
>Note that it is written so that only the sparc is affected.

Bad idea, unless 80386 C compilers always generate code to do the extra
stuff to ensure that a shift count > 32 gives a result of 0.  I suspect
few, if any, do.

>I guess this should really be logged as a bug in the mfbbitblt code.

Good idea; if the code does, in fact, depend on a shift count > 32
giving a zero result, then it's depending on something that is not
guaranteed by the C language.