Re: 64 bit implementation

[Owen Taylor <otaylor redhat com>]

On Tue, 2003-03-25 at 10:42, Sasha Vasko wrote:
> Hi
> 
> Here is a little problem that surfaced when couple guys tried to port 
> AfterStep to 64-bit Sun system: It appears that all the XIDs on the 
> client side are 64-bit long. Looking at X.h from XFree86 Xlib I see that
> indeed client XIDs will be 64-bit unsigned long, but at the same time, 
> server should use 32-bit CARD32 XIDs. What appears is that when 64-bit 
> IDs on the client are stored in 32 bit variables it produces 
> BadDrawable/BadWindow errors. I thought for a moment that problem is in 
> endiannes, but AFAIK SPARC systems are all big endian.
> 
> Now in the specs we explicitely mention 32-bit values for everything.
> Should we change it? I really am clueless about how 64-bit X should be 
> treated, so maybe more educated ppl out there can provide some insight.

When the X window system was ported to 64-bit architectures, a rather
peculiar design decision was made. 32-bit quantities such as Window
IDs, atoms, etc, were kept as longs in the client side APIs, even
when long was changed to 64 bits.

This means that when you retrieve a format-32 property using 
XGetWindowProperty, the results are an array of 64 bit longs.
Something that nobody expects. (I assume the intent was to
reduce porting difficulties for apps that were using longs
rather than the appropriate Atom/Window/CARD32/etc. 
But I think the effect instead has just been to keep everybody
confused.)

This all doesn't change at all the fact that the quantities have
only 32 bits in them, and they are 32 bits in the protocols.
It's completely a client-side API issue and should have no effect
on the WM spec.

It's possible that the reason you are seeing problems on 64-bit 
Sun but not on 64-bit alpha/ia64/etc. is in fact an endianess thing. 
Using the first 4 bytes of a 64-bit quantity works on a 
little-endian machine, but not on a big-endian machine.

Regards,
                                    Owen