Re: C/C++ PATCH to add __typeof_noqual (PR c/65455, c/39985)

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 27 Jun 2017, Martin Sebor wrote:

> > Another thing, with the current patch, __typeof_noqual__(const int)
> > would still produce "const int".  With the __atomic_load_n proposal
> > it'd return "int".  I don't know what we want to do for typenames,
> > but __typeof__(_Atomic int) produces "atomic int".
> 
> I missed that.  That seems surprising.  I would expect the trait
> to evaluate to the same type regardless of the argument (type or
> expression).  Why does it only strip qualifiers from expressions
> and not also from types?

The type stripping from atomic expressions is basically what's necessary 
for some stdatomic.h macros to work, while minimizing the risk to existing 
code.  Of course when adding _Atomic, anything whatever could have been 
done with atomic types without risk to existing code, but I suppose there 
is a case for thinking of typeof (typename) as being purely like 
parentheses - not modifying the type at all.

I'd expect __typeof_noqual to remove qualifiers from both expressions and 
type names.  There's the usual question of what should be done with arrays 
of qualified types (where C does not consider such an array type to be 
qualified, but C++ considers it to have the same qualifiers as the element 
type).  There's also the matter of qualifiers used internally by GCC to 
represent const and noreturn functions.

> Unless __typeof__ (p) q = p; declares a restrict-qualified q when
> p is a restrict-qualified pointer I don't think __remove_restrict
> is needed.  Restrict doesn't qualify a type but rather a pointer
> object it applies to so I would find the effect above unexpected

restrict acts as a type qualifier in C terms, the type being 
"restrict-qualifiers pointer to ...".  I'd expect it to work just like 
const and volatile in __typeof and __typeof_noqual.

-- 
Joseph S. Myers
joseph@codesourcery.com