Path: utzoo!censor!geac!jtsv16!uunet!richsun!ken
From: ken@richsun.UUCP (Ken Marks)
Newsgroups: comp.windows.x
Subject: Byteswapping bug in ClientMessageEvent??
Message-ID: <631@richsun.UUCP>
Date: 4 Nov 89 19:43:07 GMT
Reply-To: ken@richsun.UUCP (Ken Marks)
Distribution: usa
Organization: RICH Inc. , Franklin Park,IL
Lines: 43

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.