Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!nthropy!lowe
From: lowe@nthropy.UUCP (Andy Lowe)
Newsgroups: comp.windows.x
Subject: X11 R4 server portability problem (in Xproto.h and dix/dispatch.c)
Message-ID: <9009071653.AA09776@nth.com>
Date: 7 Sep 90 16:53:08 GMT
Lines: 76
Posted-Date: Fri, 7 Sep 90 11:53:08 CDT
To: comp-windows-x@cs.utexas.edu


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.