Proposed resolution:

Add the following entries to table 143:

Table 146 — atomic <inttypes.h> typedefs

Atomic typedef	<inttypes.h> type
...	...
atomic_intmax_t	intmax_t
atomic_uintmax_t	uintmax_t
atomic_int8_t // iff int8_t is provided	int8_t
atomic_uint8_t // iff uint8_t is provided	uint8_t
atomic_int16_t // iff int16_t is provided	int16_t
atomic_uint16_t // iff uint16_t is provided	uint16_t
atomic_int32_t // iff int32_t is provided	int32_t
atomic_uint32_t // iff uint32_t is provided	uint32_t
atomic_int64_t // iff int64_t is provided	int64_t
atomic_uint64_t // iff uint64_t is provided	uint64_t

[ 2011-03-24 Madrid ]

[ 2011-03-16: Hans reopenes and comments ]

WG14 briefly discussed LWG 1456. It turns out that they had previously made a conscious decision not to make a similar change. If C++ would deviate, this would introduce a C divergence.

We should reopen the issue and, in my opinion, probably resolve it as NAD instead. This is in a part of the standard that is there mostly for C compatibility, so introducing divergence here seems to make no sense.

[ 2011-02-16 Reflector discussion ]

Moved to Tentatively Ready after 5 votes.

[ 2011-02-15 Anthony corrects numbering/naming for N3225, Howard suggests improvement for the position of '(optional)', Daniel reorders rows in harmony to remaining entries and suggests specific optionality comments: ]

[ 2010-10-24 Daniel adds: ]

Accepting n3164 would solve this issue.

Addresses GB-129

Table 143 lists the typedefs for various atomic types corresponding to the various standard integer typedefs, such as atomic_int_least8_t for int_least8_t, and atomic_uint_fast64_t for uint_fast64_t. However, there are no atomic typedefs corresponding to the fixed-size standard typedefs int8_t, int16_t, and so forth.