lowe@nthropy.UUCP (Andy Lowe) (09/07/90)
Dear Xperts,
I am porting X11R4 to a 32-bit processor and I have run into a family
of problems that have to do with the inability of this chip to address
16-bit quantities. Generally, I have been able to work around these problems
by appropriatly adjusting the definitions of CARD16, B16, etc.
But this time I think I have discovered something that is plain wrong in dix.
in Xproto.h, an xAllocColorPlanesReply is defined:
typedef struct {
...
CARD32 redMask B16, greenMask B16, blueMask B16;
...
} xAllocColorPlanesReply;
and then used in dix/dispatch.c:
int
ProcAllocColorPlanes(client)
register ClientPtr client;
{
...
xAllocColorPlanesReply acpr;
...
if(retval = AllocColorPlanes(client->index, pcmp, npixels,
(int)stuff->red, (int)stuff->green, (int)stuff->blue,
(int)stuff->contiguous, ppixels,
&acpr.redMask, &acpr.greenMask, &acpr.blueMask))
...
so on any non-WORD64 machine acpr.redMask is a CARD32, because B16 is
#defined empty. But for us, B16 is #defined :16, even though the chip has
a 32-bit architecture.
this means that &acpr.redMask is the address of a bit field! (i.e. the address
of the enclosing word), which makes it more or less unusable. There are
many more instances of this which we have managed to address.
But the problem I am writing about is that in dix/colormap.c
the input parameters are defined:
int
AllocColorPlanes (client, pmap, colors, r, g, b, contig, pixels,
prmask, pgmask, pbmask)
...
Pixel *prmask, *pgmask, *pbmask;
...
*prmask = *pgmask = *pbmask = 0;
where Pixel is defined in colormap.h:
typedef unsigned long Pixel;
so on any machine with B16 defined (e.g. CRAY?), this codepath will
assign 32 bits of 0 into 16-bit wide bit fields, corrupting the memory
immediatly adjacent, either preceeding or succeeding depending on
alignment. is this not devo?
Suggested solutions by e-mail would be greatly appreciated.
-Andy Lowe
andy@nth.com
------------------------------------
p.s. --
My own preference is to change the calling sequence to ResolveColor,
AllocColor and AllocColorPlanes (internal to the server) to take an
xrgb structure pointer rather than pointers to the individual fields.
This structure is guaranteed to be word aligned and accesses to fields
or bitfields is legal and predictable. rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/08/90)
CARD32 redMask B16, greenMask B16, blueMask B16; This is clearly a bug, the B16s should be B32 instead. But to answer the larger question, the bitfield stuff is only there to help *client-side* 64-bit architectures. If the server even comes remotely close to building on a 64-bit system, then it's simply a miracle. It's not a configuration we expect to support.