On 30.09.2010, at 10:21, MacArthur, Ian (SELEX GALILEO, UK) wrote: > I got bitten by a similar sounding bug elsewhere in the X11 API. > > I can't now find the relevant posts, but IIRC, the key to it was the bit > where the docs say that the format argument must be one of 8, 16, or 32 > - this, it seems, is considered to be binding, so if the size is> 32, > then it is fixed at 32. > > I don't think I followed (or necessarily agreed with) the argument the > X11 guys were making for this, but it seems it essentially comes down to > being backwards compatible (I think.)
Thanks for the explanation. I was wondering WTH this was about. They define Atom as unsigned long which is 8 bytes = 64 bits on some 64-bit systems, but then they don't allow the (data) format to be 64 bits? > I have not been able to find that written down anywhere, either, but > that appears to be the Way It Works now... Would be nice to have a reference, but probably it's not worth the effort... > So, on that basis, Albrecht's fix is good, I think, though anyone > looking at that later will probably be going WTF?! When they see it... Yup, I *really* don't like this patch, but I saw the problem as you described above. We can't simply leave the argument an "Atom" and claim that it is 32 bits wide, because this wouldn't work on big-endian systems. OTOH, what we do now is problematic, since we shouldn't need to *know* the internal representation of an Atom, and thus the assumption we make (using unsigned int instead) may break in the future[1]. I suspect that there may be other similar problems in the code that we didn't see yet. I'll try to take a look later... [1] ... or on 16-bit systems where int has only 16 bits? --- WRT "going WTF?! When they see it...": I think a comment stating the reason and the STR might help. Hopefully ;-) Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
