Am Montag, dem 29.06.2026 um 13:32 +0200 schrieb Arsen Arsenović: > Joseph Myers <[email protected]> writes: > > > Note that there is an active discussion in WG14 of possibly > > introducing the term "access qualifier" for const / volatile / > > restrict, with a view to integrating named address spaces into the C > > standard. > > Ah, that seems useful. > > > _Atomic is only syntactically a qualifier in the C standard, not > > semantically, although of course in implementation terms it's like const / > > volatile / restrict to the extent that it's either present or absent on a > > type. It's possible that if the "access qualifier" concept is introduced, > > it would make sense to redefine _Atomic in the C standard as being a > > qualifier that's not an access qualifier; it has the property of > > qualifiers that it has no meaning for rvalues, but not the access > > qualifier properties that the layout is the same as for the unqualified > > type (_Atomic can increase size and alignment) or, thus, that it's safe to > > convert a pointer to one to a more-qualified type. (Hence various places > > that use e.g. TYPE_QUALS_NO_ADDR_SPACE_NO_ATOMIC because they want to deal > > with access qualifiers only.) > > Likewise I imagine address spaces wouldn't be an access qualifier, if > those get added. > > But, address space qualifiers can, sometimes, participate in implicit > conversion. T AS1* can implicitly convert into T AS2* if AS1 is a > superset of AS2. > > But, this certainly means that I was wrong in saying: > > /* Returns true if qualifiers in SUBSET are completely included in SUPERSET. > > In general, this means that an object qualified per SUBSET can be used > as if > it was qualified per SUPERSET safely (e.g. 'T' as 'const T', or 'const > T' as > 'const volatile AS1 T', presuming that AS1 is a superset of the generic > address space). */ > bool quals_includes_p (qualifier_set superset, qualifier_set subset); > > ... as that isn't true if _Atomic is involved. > > On further reflection, it is a bit strange to have TYPE_QUAL_ATOMIC. > Perhaps it'd make more sense to have an ATOMIC_TYPE type constructor, > where a (possibly cvr-AS-qualified) ATOMIC_TYPE wraps an unqualified > type. I mostly don't look at the C standard too much, but ISTM at a > glance that _Atomic is much more similar to a type constructor than a > qualifier generally. > > TYPE_ATOMIC is used in ~70 locations, so it may be a doable change. > > Note that the C++ FE never uses TYPE_ATOMIC.
Yes, atomic as specified should not be a qualifier. It is a mess both from a standardization and also from an implementation point of view. And with my "user hat" on, I can say it is also a pain because it prevents the use of standard atomics in many applications. It would be really useful to have a true atomic qualifier where the qualified type is ABI-compatible to the unqualified (same representatio and alignment), but this probably would need a new qualifier to avoid breaking changes. Martin
