Revisiting generalized lvalues

[Michael Krasnik]

Andrew Pinski wrote:
>>I don't know if it's too late, but there is yet another reason
>>for the use of generalized lvalues besides just ignorance:
>>using them in macros that verify pointer and struct usage
>>in a large framework. A comma expression makes it very
>>convenient, for example (just a general idea):
>>
>>#ifdef  PRODUCTION
>>#define X_ABC(x)       ( check( x ), x->abc )
>>#else
>>#define X_ABC(x)        x->abc
>>#endif
>>
>>which expands
>>
>>     X_ABC(x) = y;
>>
>>to:
>>
>>     ( check( x ), x->abc ) = y;
>>
>>It is something that is used during development only and
>>is switched off for the production builds. C++ compatibility
>>is not an issue either.
> 
> 
> 
> GCC does this through another extension, like:
> #ifdef CHECKING
> #define CHECK_X(x)   	({const tree __t = x; check(__t); __t; })
> #else
> #define CHECK_X(x)	x
> #endif
> #define X_ABC(x) 	CHECK_X(x)->abc
> 
> 
> -- Pinski
> 

Your example is a fancier way of rewriting our macros as:

#ifdef  PRODUCTION
#define X_ABC(x)       ( check( x ), &x )->abc
#else
#define X_ABC(x)        x->abc
#endif

to get around the "invalid lvalue" error. It's fine for a
distilled simple example, but quickly becomes ugly for
real multi-level nested macros. Well, I guess we have to
forget about elegance and use the same tricks we do for
other compilers...

Thanks,

/m