Date: Wed, 10 Feb 2021 17:41:26 +0000
On Tue, 9 Feb 2021, Hans Boehm via Liaison wrote:
> We've had similar discussions before on the WG14 reflector. The concern
> here is basically that if _Atomic were to be usable as a real type
> qualifier that can be added to parameters, then _Atomic T and T should have
> the same representation.
Whereas in fact it's not a qualifier at all, other than purely
syntactically (_Atomic T is an alternative syntactic notation for _Atomic
(T)), and it's explicit in the C standard that references to qualified and
unqualified types do not count _Atomic as a qualifier by default.
> I think C really wants the type qualifier to work, since
> it doesn't have atomic_ref<>. So something has to give, and we've had
> different proposals about what that should be.
Whatever system you might add for atomic operations on non-atomic data, I
think making the syntactic-qualifier _Atomic into something semantically a
qualifier would be an unreasonably incompatible way of adding such a
feature.
> We've had similar discussions before on the WG14 reflector. The concern
> here is basically that if _Atomic were to be usable as a real type
> qualifier that can be added to parameters, then _Atomic T and T should have
> the same representation.
Whereas in fact it's not a qualifier at all, other than purely
syntactically (_Atomic T is an alternative syntactic notation for _Atomic
(T)), and it's explicit in the C standard that references to qualified and
unqualified types do not count _Atomic as a qualifier by default.
> I think C really wants the type qualifier to work, since
> it doesn't have atomic_ref<>. So something has to give, and we've had
> different proposals about what that should be.
Whatever system you might add for atomic operations on non-atomic data, I
think making the syntactic-qualifier _Atomic into something semantically a
qualifier would be an unreasonably incompatible way of adding such a
feature.
-- Joseph S. Myers joseph_at_[hidden]
Received on 2021-02-10 11:41:35