Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Rationale for the C11 _Atomic specifier-vs-qualifier syntax irregularity?

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 shifting 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".

like image 917
o11c Avatar asked Apr 03 '16 03:04

o11c


1 Answers

The rationale is found in N1485:

The _Atomic keyword also can also be used in the form _Atomic(T), where T is a type, as a type specifier equivalent to _Atomic T. Thus, _Atomic(T) x, y; declares x and y with the same type, even if T is a pointer type. This allows for trivial C++0x compatibility with a C++ only _Atomic(T) macro definition as atomic<T>.

like image 74
T.C. Avatar answered Nov 10 '22 22:11

T.C.