A problem with enums in XCode (2.4).

[Roger H. <rog...@mi...>]

I know this occurs in several places within Quesa, some of which I  
have fixed in my own copy, and Peter tried to explain the problem to  
you and failed. I have now found another occurrence and while it is  
fresh in my mind, I hope I can explain it clearly.

In QuesaRenderer.h there is an enum called TQ3CSGObjectID. This has a  
final value 0xFFFFFFFF to try to force it to 32 bits. It also has an  
initial value of -1. This worked fine with CodeWarrior where 'enum  
always int' took care of it all anyway (note it is not called enum  
always UNSIGNED int).

The second registration in E3Renderer_RegisterClass is:


  		qd3dStatus = Q3_REGISTER_CLASS (	kQ3ClassNameAttributeCSGID,
											NULL,
											E3CSGAttribute ) ;


This macro expands to call E3ClassTree::RegisterClass with a final  
parameter of sizeof ( E3CSGAttribute ) which is 20 in XCode (2.4) but  
is 16 on CodeWarrior.

This means that when I retrieve the value of a CSGAttribute by  
passing the address of a long, it copies 8 bytes of data into my  
'long' and  corrupts whatever comes after it in memory.

This is because E3CSGAttribute is:

class E3CSGAttribute : public E3Attribute // This is a leaf class so  
no other classes use this,
								// so it can be here in the .c file rather than in
								// the .h file, hence all the fields can be public
								// as nobody should be including this file
	{
Q3_CLASS_ENUMS ( kQ3AttributeTypeConstructiveSolidGeometryID,  
E3CSGAttribute, E3Attribute )
public :

	TQ3CSGObjectID			instanceData ;
	} ;

E3Attribute is 12 bytes long and XCode adds 8 bytes for  
TQ3CSGObjectID whereas CodeWarrior only adds 4 bytes.

Changing the final 0xFFFFFFFF to 0x7FFFFFFF cures the problem.

I have tried 0xFFFFFFFFL, 0xFFFFFFFFU and 0xFFFFFFFFUL and none of  
them cure the problem. Changing the -1 to  0xFFFFFFFFUL makes the  
field the correct size, but probably host programs would not work  
correctly, especially if they test for less than zero. 0x7FFFFFFF  
seems to me to be the best solution.

Roger.