Sat, Jan 25, 2003 at 04:49:02PM +1100, matthew green:
> 
>    so, i switched my desktop from a ss20 to an ultra 2, the weekend
>    before sparc smp went it (had i known, i would have waited), to
>    get more cpu.  i am having problems with X on a gx+.  there
>    are a few issues that seem to be LP64 related.  eg:
>    
>    	- kbd leds are not handled properly
>    	- Xsun bus-error when colormap switches (think i've nailed this one)
>    	etc.
>    
>    to be sure i'm doing something which will be accepted for commit, is there
>    some web-page with guidelines for making things LP64 safe?
>    
>    for example; there are several uses of (unsigned) longs.  in this case,
>    so far, most of these seem to be harmless, but i've found a few that
>    really should be a 32bit int.  when folks are making LP64 fixes, is it
>    customary to just leave longs that do not matter as is, or make them of
>    the "intended" type?
>    
> 
> well, it depends.. it's usually better to clean this up anyway
> but if it's really huge amounts of code change for no real 
> reason i tend to avoid it and just do the necessary parts.
> 
> are you using xsrc/xc or xsrc/xfree ?  it would be nice if you
> were using the latter...

thanks.  i didnt realize that xfree had sparc servers, but i will
restart with xfree.

i figured a good starting point might be to clean-up the o/p of
gcc -Wall...

what is normally done for printfs of addresses? eg

	printf("%d", ptr - otherptr);

i noticed jason's comment

	Use <inttypes.h> and PRIx64 or the like.

but i can't figure out if this is portable and doesnt seem to apply
to addresses.

> 
> thanks for working on this!

heh, dont thank me yet. :)