[AC21.5R21.4] Patch: fix cut & past problem on 64 bit platforms

[Martin Buchholz]

>>>>> "SJT" == Stephen J Turnbull <stephen at 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 at 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