------- Comment #3 from anders at kaseorg dot com 2009-11-27 07:33 -------
> my inclination is that we should eliminate the inconsistent attempts to give
> rvalues qualified types in some cases, and say that if the operand of typeof
> is not an lvalue it never has a qualified type.
Should typeof ever return a qualified type? It is easy to add qualifiers to a
type if they are desired (const typeof(foo)), but seems difficult to remove
them.
For example, seemingly reasonable macros like
#define MAX(__x, __y) ({ \
typeof(__x) __ret = __x; \
if (__y > __ret) __ret = __y; \
__ret; \
})
currently fail when given a qualified argument:
const int c = 42;
MAX(c, 17); /* error: assignment of read-only variable __ret */
This bug report was motivated by my attempts to fix a macro like this, by
replacing typeof(__x) with something that strips qualifiers. These all fail to
strip qualifiers:
typeof( ({ __x; }) )
typeof( ((typeof(__x)(*)(void)) 0)() )
typeof( (typeof(__x)) (__x) )
This seems to work, but only for numeric and pointer types:
typeof( (typeof(__x)) 0 )
This succeeds at stripping qualifiers for numeric types, but for some reason it
promotes char and short to int, and it fails to strip qualifiers for
non-numeric types:
typeof( 1 ? (__x) : (__x) )
Much confusion would be avoided if typeof(__x) just stripped qualifiers to
begin with.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985
