Patch: fix cut & past problem on 64 bit platforms

Glynn Clements glynn at gclements.plus.com
Sat Feb 17 09:40:53 EST 2007


Stephen J. Turnbull wrote:

>  > For details please have a look at
>  > 
>  > http://bugzilla.novell.com/show_bug.cgi?id=244613

> (2) Now, this looks like a bug in the 64-bit X libraries to me.  What
> happens if it gets fixed?

It isn't a bug, it's a design decision (a bad one, IMHO). IOW, it
isn't going to get "fixed".

The latest version of the XGetWindowProperty() manpage is more
explicit:

       If the returned format is 8, the returned data is represented as a char
       array.  If the returned format is 16, the returned data is represented
       as a short array and should be cast to that type to obtain the ele-
       ments.  If the returned format is 32, the returned data is represented
       as a long array and should be cast to that type to obtain the elements.

The sizes used by XGetWindowProperty() (e.g. bytes_after_return) refer
to the sizes in terms of the X protocol (e.g. 4 bytes for CARD32),
which isn't necessarily the same as used in the client.

Similar issues apply to properties whose values are structures (e.g. 
XSizeHints). The actual property will be defined in terms of CARD32s,
but the corresponding Xlib structure will typically contain a mix of
"int"s and "long"s.

This sort of issue is the main reason why the 64-bit Windows ABI has a
32-bit "long"; there are just too many cases where structures
containing "long" fields get written directly (fwrite() etc) to files
or sockets.

-- 
Glynn Clements <glynn at gclements.plus.com>



More information about the XEmacs-Beta mailing list