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:
> > 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.
> What about _Atomic? Should it also be removed? If yes, how would
I think so. I'd think of this as being something like type as an rvalue,
which is the unqualified, non-atomic version of the type. Which is
appropriate for various uses of type-generic macros where you declare
temporary variables, and there is no need for those temporaries to be
volatile, atomic, etc., even if the inputs or outputs for the macro are.
> one then generically define a cv-unqualified object of an atomic
> type when given a const- or volatile-qualified atomic type or object?
I'm doubtful of the utility of that.
> Yes, syntactically restrict is (kind of like) a qualifier, but
> semantically it's nothing like it (the standard says it's more
> akin to a storage specifier). Most (but not all) of the essential
Storage class specifiers aren't part of the type system at all. All the
usual rules for qualified types apply to restrict (whereas they *don't*
necessarily apply to _Atomic).
> In my mind, all this speaks in favor of introducing simpler building
> blocks. From its name alone, the expected effects of a __remove_const
> or __remove_atomic built-in (not to mention their utility) are far
> clearer than those of __typeof_noqual__.
If you *only* have blocks like that, you can't then write code that also
removes whatever qualifiers might be added in future - you keep needing to
update the generic code for future qualifiers. For C90 you'd have had
__remove_const and __remove_volatile, but then would have needed to update
again for restrict, again after that for address spaces, and again after
that for _Atomic.
I.e., just having blocks to remove qualifiers of kind X is not sufficient
without "remove all qualifiers (possibly except these kinds)" as well. I
suppose you could have __remove_quals (const volatile _Atomic, expr) and
__remove_quals_except (_Atomic, expr) or similar (with some keyword that
goes in there to mean "any address space").
Joseph S. Myers