Martin's expression for the item size of XGetWindowProperty buffers

[Martin Buchholz]

>>>>> "SJT" == Stephen J Turnbull <turnbull at sk.tsukuba.ac.jp> writes:

SJT> I'm taking this off -patches, as I don't intend to do anything about it
SJT> immediately; in fact, I intend to wait for a request from Vin to port
SJT> to 21.4. :-)  Anybody who wants to write up a patch, feel free!

SJT> Martin Buchholz writes:

>> 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;


SJT> Thanks!  But I don't see the advantage to configure detection of
SJT> CHAR_BIT and friends; just use sizeof(type)*8.  And for modern
SJT> compilers, optimization should result in your "mostly portable"
SJT> simplified form, right?  (Maybe it would be best to start with
SJT> "format == 32 ? ..." for slightly stupid compilers?)  Not that it
SJT> matters; this is surely going to be swamped by network latency.

I was not thinking at all about optimization.

Sure, LONG_BIT is exactly the same as sizeof(long)*CHAR_BIT.
Is it slightly more readable?  If yes, then we should use it.
I generally prefer to use standardized symbols like LONG_BIT
if they are even slightly more convenient or readable,
fixing configure for platforms where they are not (yet) available.

Martin