There is a related "what" question here: C11 grammar ambiguity between _Atomic type specifier and qualifier
What I'm interested is why, since the C11 rationale hasn't been published yet, and this seems needlessly complex.
The grammar includes both of these (and resolves the ambiguity in favor of shift
ing the (
rather than reduce
(which would otherwise be in lookahead if followed by a declarator
or abstract-declarator
)), reachable from declaration-specifiers
or specifier-qualifier-list
:
atomic-type-specifier: _Atomic ( type-name )
type-qualifier: _Atomic
This leads to the following code:
int i1;
int (i2); // valid, same as i1 - usually seen in the context of pointer-to-function or pointer-to-array
int _Atomic a1;
int _Atomic (a2); // invalid
_Atomic (int) a3; // valid, same as a1
Thoughts:
_Atomic
must not modify an array or function. Barring redundant parentheses around a declarator, this means it would be valid to #define _Atomic(x) x _Atomic
(if it were legal to #define
keywords of course).
When it occurs as a qualifier
, _Atomic
is the same syntactical part as const
, and C programmers are already used to putting const
on the correct side, so it can't be for "ease of use".
The rationale is found in N1485:
The
_Atomic
keyword also can also be used in the form_Atomic(T)
, whereT
is a type, as a type specifier equivalent to_Atomic T
. Thus,_Atomic(T) x, y;
declaresx
andy
with the same type, even ifT
is a pointer type. This allows for trivial C++0x compatibility with a C++ only_Atomic(T)
macro definition asatomic<T>
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With