DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending] Link: http://www.fltk.org/str.php?L2308 Version: 1.3.0 Matt, you wrote: > To answer your questions: nothing is going to happen. As long as I > use "long" to read and write, and the "void*" is equal in size or > bigger, the "junk" bits will be clipped by the casts, no matter if > that will be the first bits or last bits (MSB, LSB). The "union" > approach would also always work. I'm afraid that I disagree here. First, the point was that we were talking about the case that sizeof(void*) > sizeof(long). The case "=" is trivial. Second, I was writing about a case where you use the "long" union member to write and the "void *" union member to read the userdata field. The former is possible (and we can't prevent it) by the user calling widget->argument(int), and the latter is the way a callback is called by FLTK. Then, on a big endian system, writing the long union member would write the first 4 bytes only (the following 4 bytes are undefined). When FLTK calls the callback, it uses the "void *" member variable, and this means that the "LSB" will be the last byte (big endian), and thus the last 4 bytes will become the low order 4 bytes of the void * pointer. Casting this to a long in the callback will result in 4 undefined bytes. Strictly spoken: a union's value is undefined, if you use another member variable to read than you used to write, and we wouldn't be able to control this because of the different calls (argument() and userdata()) that are available to set the value. Fortunately, this would probably be moot, since the only systems with sizeof(long) < sizeof(void *) are Windows systems, and AFAIK Windows doesn't work on big endian machines. ;-) But anyway, I recommend not to use a union for the given reasons. --- Matt, you also wrote: > Oh, and there is a perfect solution, too: we can have two member > variables, a pointer AND a long. But that needs more space and would > be incompatible to existing code. We could do this from an ABI point of view now, but we would pose a new restriction on setting the userdata (aka. argument()) value and we would probably need to differentiate the callback signature we call depending on which way was used to set the userdata value. At least we would also need a flag that tells us which of the variables was set in the last call. If we do that, then we can also use a union, because we can then use the same member for reading that was used for writing. Or something similar. ... Link: http://www.fltk.org/str.php?L2308 Version: 1.3.0 _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
