2441. Exact-width atomic typedefs should be provided

Section: 32.5.8 [atomics.types.generic] Status: C++17 Submitter: Stephan T. Lavavej Opened: 2014-10-01 Last modified: 2017-07-30

Priority: 0

View all other issues in [atomics.types.generic].

View all issues with C++17 status.

Discussion:

<atomic> doesn't provide counterparts for <inttypes.h>'s most useful typedefs, possibly because they're quasi-optional. We can easily fix this.

[2014-11, Urbana]

Typedefs were transitional compatibility hack. Should use _Atomic macro or template. E.g. _Atomic(int8_t). BUT _Atomic disappeared!

Detlef will look for _Atomic macro. If missing, will open issue.

[2014-11-25, Hans comments]

There is no _Atomic in C++. This is related to the much more general unanswered question of whether C++17 should reference C11, C99, or neither.

[2015-02 Cologne]

AM: I think this is still an SG1 issue; they need to deal with it before we do.

[2015-05 Lenexa, SG1 response]

Move to SG1-OK status. This seems like an easy short-term fix. We probably need a paper on C/C++ atomics compatibility to deal with _Atomic, but that's a separable issue.

[2015-10 pre-Kona]

SG1 hands this over to LWG for wording review

Proposed resolution:

This wording is relative to N3936.

1. Change 32.5.8 [atomics.types.generic] p8 as depicted:

   -8- There shall be atomic typedefs corresponding to the typedefs in the header <inttypes.h> as specified in Table 147. atomic_intN_t, atomic_uintN_t, atomic_intptr_t, and atomic_uintptr_t shall be defined if and only if intN_t, uintN_t, intptr_t, and uintptr_t are defined, respectively.

2. Change 99 [atomics.types.operations.req], Table 147 ("atomic <inttypes.h> typedefs"), as depicted:

   Table 147 — atomic <inttypes.h> typedefs

   Atomic typedef	<inttypes.h> type
   atomic_int8_t	int8_t
   atomic_uint8_t	uint8_t
   atomic_int16_t	int16_t
   atomic_uint16_t	uint16_t
   atomic_int32_t	int32_t
   atomic_uint32_t	uint32_t
   atomic_int64_t	int64_t
   atomic_uint64_t	uint64_t
   …