[comp.windows.x] Byteswapping bug in ClientMessageEvent??

ken@richsun.UUCP (Ken Marks) (11/05/89)

Has anybody tried to send long values in the data union of a ClientMessageEvent
across different machine architectures (and succeeded)?

The scenario:

There is an X client running locally on a sun 3/60 which is interested in
obtaining the window id of another client which happens to be running remotely
from a sun 386i.  So the remote client executes some code akin to the
following:

		.
		.
		.

    XClientMessageEvent event;

    event.type = ClientMessage;
    event.window = destination_window;
    event.message_type = REGISTRATION_EVENT;

    event.format = 32;

    /* event.format = 8; */

    event.data.l[0] = 0x11223344;
    event.data.l[1] = my_window;

    XSendEvent(dpy, ..., &event);

		.
		.
		.


The event is received by the local client but the values seem to have been
diced, sliced, and minced.  For example, event.data.l[0] comes out as
0x3344004c (close but no cigar).  For the moment, I have resorted to changing
the event format to 8 (sending the data as a set of 20 octets instead of 5
longs).  I use the value in event.data.l[0] to determine if any byte swapping
needs to be done manually.

I would be interested to know if this is an old (known) problem, if it has been
fixed during the rewrite of X11R4, or if it is a new one.

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (11/05/89)

Yes, this is an R3 bug we fixed long ago, but we've never put out a
public patch for it, sorry.

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (11/05/89)

I should have added, I think the fix for this was to go into
server/dix/swaprep.c, in SClientMessageEvent(), under case 32:,
and change the cpswaps's to cpswapl's, but I don't guarantee it.