Re: [AC21.5R21.4] Patch: fix cut & past problem on 64 bit platforms
>>>> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> Hi Martin! Good to hear from you, even if I have to respectfully
SJT> disagree with your suggestion.
SJT> Martin Buchholz writes:
>> >>>> "SJT" == Stephen
J Turnbull <stephen(a)xemacs.org> writes:
SJT> + safe. (We could replace the factor 2 with (sizeof(long)*8/32.)
>
> Instead of "we could" why not actually use the more meaningful
> symbolic expression?
SJT> Because it needs to be done *throughout*, rather than just fixing it
SJT> once here. And it's begging to be a constant named FORMAT32_ITEM_SIZE,
SJT> don't you think? I want to leave that reminder for the benefit of
SJT> whoever fixes this thoroughly.
Project: add configury for LONG_BIT
> Make sure there's enough configury infrastructure to define
the
> stdint.h types
>
> uint16_t
> uint32_t
> uint64_t
SJT> We already have this for Berkeley DB, but it's not appropriate for use
SJT> here:
> and then in x-select.c one should have code more like
>
> (code sketch only)
>
> Lisp_Object uint32_t_to_lisp (uint32_t x)
SJT> This is conceptually wrong, isn't it? Between the CARD32 in the X
SJT> protocol and the buffer in x-select.c the gods have chosen to
SJT> interpose Xlib. According to the interface defined by Xlib, it's not
SJT> a uint32_t, it's a long. Ie, it might be an int32_t or an int64_t (or
SJT> possibly something else ;-) depending on the platform or even the
SJT> library we link to.
Obviously I was not familiar with this API.
I checked XGetWindowProperty(3X) and saw with horror
prop_return
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 elements. If the actual_format_return
is 32, the property data will be stored as an
array of longs (which will be 64-bit values that
are null padded in the upper 4 bytes on a 64-bit
application).
And no need to compute nitems? the API provides this
nitems_return
Returns the actual number of 8-bit, 16-bit, or
32-bit items stored in the prop_return data.
The "expansion factor" seems to be
format == 8 ? CHAR_BIT / format :
format == 16 ? SHORT_BIT / format :
format == 32 ? LONG_BIT / format
which can mostly portably be simplified to
format == 32 ? LONG_BIT / 32 : 1;
> Yes, it's a fair amount of work to do this right.
SJT> Yup. That's why I didn't try at this point, I don't have the Joules
SJT> to spare.
Martin
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches