On 03.10.2010, at 22:26, Ian MacArthur wrote: > I guess that MS have a ton of code that assumes sizeof(long) == > sizeof(int).
I read some articles about MS's decision to keep this, and one of the main argument was that the size of "persistent" data should not change. You may ask, what do they mean with this? For instance bitmap files (!), because the bitmap header is a structure that is also defined as a memory image (and they seem to imply that you read a bitmap file directly into memory and use its header as is). There are other reasons, e.g. that 32-bit apps. wouldn't be able to communicate with 64-bit apps if the in-memory sizes of data structures would change. Design problems from win-16 times, maybe. No further comments... > We (fltk) have a few places where we have kind of assumed that > sizeof(long) == sizeof(void*), but only in so far as we store a thing > that is actually a long in a void*, so I think that we only really need > the void* to be as big or bigger than a long. > > But with recent gcc variants, that will not fly without some fancy > casting or... > > I don't know what's best. Maybe we should just create a union that holds > a void* and a long and use that to convert the user_data back and forth. > > Any ideas? Answers on a postcard please. I don't think that a union would help, because this would maybe leave undefined bits in the user_data_ member, depending on the access to the union. Using casts and storing the full data size seems more appropriate to me. That said, I'm not keen on changing the API, but maybe Yuri's fl_long patch would be *one* way to go. At least it would keep the argument sizes consistent, and it would probably work also on other systems with different long and pointer sizes (even on big-endian). Sorry for the oversized postcard ;-) Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
