------- 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