> We're moving a large ARM based project from 2.95 to the 4.2.1 compiler and it 
> generates of type-punning warnings. The warnings say
> 
> "warning: dereferencing type-punned pointer will break strict aliasing rules"
> 
> and always come on PxConfigReadInt() calls like this:
> 
> PxConfigReadInt( section, "pwrunits", DPWRW, (int *)&buf->pwrunits);
> 
> It seems not to like the (int *) cast on the unary & operator when the pointer references an enum type. Changing the code like this eliminates the warning
> 
> int tp;
> tp = (int) buf->pwrunits;
> PxConfigReadInt( section, "pwrunits", DPWRW, &tp);
> buf->pwrUnits = tp;
> 
> but that seems like stupid-work.
> 
> Strict aliasing can be turned off but without fully understanding the issue 
> that seems like a questionable move.
> 
> Where is the type-pun in this call? I don't see it, but then I'm no expert at 
> C arcana.

From the GCC documentation: For C (and C++),  about -fstrict-aliasing
     
     this activates optimizations based on the type of expressions.  In
     particular, an object of one type is assumed never to reside at
     the same address as an object of a different type, unless the
     types are almost the same.  For example, an `unsigned int' can
     alias an `int', but not a `void*' or a `double'.  A character type
     may alias any other type.

The problem is because the enum size is "unspecified", it could be implemented as char.   The casted pointer may be 
pointing to an object of a different size, hence the warning.  

The solution you mentionned is not bad at all, it makes your code portable and type safe.  You can't assume size( enum )
 == sizeof ( int ),

Or you can provide a cover function a la MyPxConfigReadEnum if you have lots of those calls.

Or if you are really desperate you disable the optimisation that trigger that warning with -fno-strict-aliasing