Martin's expression for the item size of XGetWindowProperty buffers

Takashi Iwai tiwai at suse.de
Mon Feb 19 06:46:45 EST 2007


At Sun, 18 Feb 2007 11:47:19 -0800,
Martin Buchholz wrote:
> 
> >>>>> "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.

But, anyways, you don't have to use previous configure for such a
thing.  Simply define it as:

#define LONG_BIT	(sizeof(long) * 8)

and the compiler will optimize out the codes.


Takashi



More information about the XEmacs-Beta mailing list