Several different things are going on here. First, on OS X, GLuint is defined as an 'unsigned long', not an 'unsigned int'. This is I think the heart of the difficulty. While unsigned long doesn't make a whole lot of sense now, I think the reasons become more apparent as you move to 64-bit.
Next, yes G5 is 64-bit and is currently the only 64-bit Mac processor. (Speculation is that Apple can't launch PowerMac and Xserve replacements until Intel has a viable 64-bit processor to sell.) However, by default on OS X, G5 sizes match the 32-bit counterparts (presumably for binary compatibility). Running the osgunititests on a PowerMac G5 (with -arch ppc): sizeof(bool)==4 sizeof(char)==1 sizeof(short)==2 sizeof(int)==4 sizeof(long)==4 sizeof(long int)==4 sizeof(long long)==8 sizeof(float)==4 sizeof(double)==8 sizeof(std::istream::pos_type)==136 sizeof(std::istream::off_type)==8 sizeof(OpenThreads::Mutex)==8 sizeof(std::string)==4 Notice that except for sizeof(bool), these are all the same sizes as the Intel Mac that David Lscbe listed. (Apple was trapped in 4-byte bools on PowerPC for backwards compatibility and I think Intel finally gave them the chance to switch over as the default.) So one thing that was omitted in the unit tests were the pointer sizes. So here are a few: Size of unsigned int: 4 Size of unsigned long (aka GLuint on PPC OS X): 4 Size of int*: 4 Size of unsigned int*: 4 Size of unsigned long*: 4 Size of void*: 4 Size of void* is still actually 4. But, on OS X, there are extra gcc flags that lets you take advantage of all the 64-bit capabilities of the G5. Formerly the flag was known as -mpowerpc64, but now with Universal Binaries, it has been rolled into the -arch flag. So FYI, when you build a Universal Binary, there are currently 3 different possible architectures, ppc, i386, and ppc64. Currently for OSG, I don't build the ppc64 variant because I don't believe Apple's GL driver takes advantage of 64-bit memory space. Also, I speculate that a 4th variant, ia64, will appear once Apple starts shipping 64-bit x86 systems. Anyway, if I build as ppc64 on this same G5, here are the results: sizeof(bool)==1 sizeof(char)==1 sizeof(short)==2 sizeof(int)==4 sizeof(long)==8 sizeof(long int)==8 sizeof(long long)==8 sizeof(float)==4 sizeof(double)==8 sizeof(std::istream::pos_type)==136 sizeof(std::istream::off_type)==8 sizeof(OpenThreads::Mutex)==16 sizeof(std::string)==8 Size of unsigned int: 4 Size of unsigned long (aka GLuint on PPC OS X): 8 Size of int*: 8 Size of unsigned int*: 8 Size of unsigned long*: 8 Size of void*: 8 Notice the size of long and the size of pointers have grown to 8. size of int is still at 4. (size of bool is at 1). So in 32-bit mode, casting from unsigned int* to GLuint* (which is unsigned long*) shouldn't really be a problem since the sizes are the same. But once you cross over into 64-bit, your sizes are different and you have a legitimate potential problem. I think Apple picked unsigned long as the basis of GLuint because they wanted to leave the option open to 64-bit in OpenGL even though they don't do such now. So finally for the cast problem, even though under 32-bits, the sizes are the same, this still triggers an error under gcc 4. I think it's because the compiler decides that int and long should be treated differently since the sizes could potentially be different. This is also why I've said gcc 4 is more anal retentive about this type of stuff. gcc 3.3 lets this cast slide with only a warning, not an error. -Eric _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
