This is the mail archive of the
mailing list for the GCC project.
Re: C/C++ PATCH to add __typeof_noqual (PR c/65455, c/39985)
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