https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2017-07-25
CC| |egallager at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |polacek at redhat dot
com
Ever confirmed|0 |1
--- Comment #4 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Anders Kaseorg from comment #3)
> > 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.
Related: bug 65455. Marek Polacek has been posting patches to the gcc-patches
mailing list towards solving this; latest message in the chain was:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01146.html
Assigning this to him since he's already been working on it anyways.
