Issue 1105: Issues with atomic integer types in <stdatomic.h>

Authors: Jay Ghiron
Date: 2026-09-09
Submitted against: C23
Status: Open

The types intptr_t and uintptr_t are optional, but there does not seem to be any wording that makes atomic_intptr_t and atomic_uintptr_t optional as well. Issue 1073 would also apply to atomic_charN_t if issue 1074 is resolved as requiring freestanding implementations to support <stdatomic.h> if __STDC_NO_ATOMICS__ is not defined.

There also does not appear to be any wording that actually requires the atomic_* types other than atomic_flag to actually be atomic or integer types. The name of the subclause "Atomic integer types" is nonnormative, as far as I understand. Is there any reason to not say that the atomic type names are the same as the direct types, and instead just require equivalent representations and alignment requirements? The following paragraph that describes conversions to atomic_bool also would not make sense if atomic_bool was not an integer type or an atomic integer type.

Note that C++ also provides atomic_int8_t, atomic_int16_t, atomic_int32_t, atomic_int64_t, atomic_uint8_t, atomic_uint16_t, atomic_uint32_t, and atomic_uint64_t if the corresponding non-atomic types are provided.