> > The implication also appeared to be that "internally" the X system > > "knew" that 32 might not mean 32 on some platforms. > > The intent seemed to be that you just pass the Atom as > normal, but set > > the size to 32 on any host where the "true" size was>= 32 > and leave it > > at that. > > That did not make me any happier about this as a solution. > > Well, then I don't understand why they don't allow 'format' to be 64. > > But, anyway, that's interesting. That would mean that we could, for > instance, use an array of (64-bit) Atoms (where applicable), say that > the format is 32, and it would find all the array elements correctly? > I mean: on 32-bit AND on 64-bit systems, little- and big-endian > as well? > > _That_ would be interesting to see documented somewhere. This would > at least help to make the code "better" (for some value of "better"), > because you wouldn't need to cast all Atom's. > > #define SIZEOF_ATOM (sizeof(Atom)>32 ? 32 : sizeof(Atom)) > > Is this what we are supposed to (and maybe should) do? If this > is well-documented, I'd be inclined to do it this way rather than > moving and casting Atoms to other types.
I just don't know - I'm way out of my depth with this... The man page seems to say (regarding returned lists of items...) "If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes)." That may apply to the atom we write too, then? Or possible not, I don't know. This seems relevant: http://www.mail-archive.com/[email protected]/msg198575.html Seems to be describing the same cut/paste problem, for much the same reason... They seem to be suggesting that something like the SIZEOF_ATOM scheme you (Albrecht)proposed would indeed work here. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
