Thomas Plum, [email protected]
November 4 2010
WG14/N1535 Synthesis re _Atomic
Changes to 6.2.5 Types:
Add a new bullet to para 20:
- An atomic type describes the type designated by the construct
_Atomic(
type-name)
. (Atomic types are a conditional feature that implementations need not support; see 6.10.8.)
Change para 27:
_Atomic qualifier , which may combine with. The presence of thevolatile
andrestrict
_Atomic
qualifier designates an atomic type. The size, representation, and alignment of an_Atomic-qualifiedatomic type need not be the same as those of the corresponding unqualified type. Therefore, this Standard explicitly uses the phrase "atomic, qualified, or unqualified type" whenever the atomic version of a type is permitted along with the other qualified versions of a type. (Atomic types are a conditional feature that implementations need not support; see 6.10.8.)
Globally change _Atomic-qualified
to atomic
.
Change 6.3.2.1 para 2:
... If the lvalue has qualified type, the value has the unqualified version of the type of the lvalue; if the lvalue has atomic type, the value has the non-atomic version of the type of the lvalue; otherwise, the value has the type of the lvalue....
Change 6.5.2.4p1:
The operand of the postfix increment or decrement operator shall have atomic, qualified, or unqualified real or pointer type, and shall be a modifiable lvalue.
Change 6.5.3.1p1:
The operand of the prefix increment or decrement operator shall have atomic, qualified, or unqualified real or pointer type, and shall be a modifiable lvalue.
Change 6.5.4p2:
Unless the type name specifies a void type, the type name shall specify atomic, qualified, or unqualified scalar type, and the operand shall have scalar type.
Change 6.5.16p3:
An assignment operator stores a value in the object designated by the left operand. An assignment expression has the value of the left operand after the assignment,110) but is not an lvalue. The type of an assignment expression is the type
of the left operand unless the left operand has qualified type, in which case it is the unqualified version of the type of the left operandthe left operand would have after lvalue conversion. The side effect of updating ....
Change 6.5.16.1p1:
One of the following shall hold:111)
- the left operand has atomic, qualified, or unqualified arithmetic type, and the right has arithmetic type;
- the left operand has
aan atomic, qualified, or unqualified version of a structure or union type compatible with the type of the right;- the left operand has atomic, qualified, or unqualified pointer type, and (considering the type the left operand would have after lvalue conversion) both operands are pointers to qualified or unqualified versions of compatible types, and the type pointed to by the left has all the qualifiers of the type pointed to by the right;
- the left operand has atomic, qualified, or unqualified pointer type, and (considering the type the left operand would have after lvalue conversion) one operand is a pointer to an object type, and the other is a pointer to a qualified or unqualified version of
void
, and the type pointed to by the left has all the qualifiers of the type pointed to by the right;- the left operand is
aan atomic, qualified or unqualified pointer, and the right is a null pointer constant; or- the left operand has type atomic, qualified or unqualified
_Bool
, and the right is a pointer.
Change 6.5.16.2p1:
For the operators
+=
and-=
only, either the left operand shall beaan atomic, qualified, or unqualified pointer to a complete object type, and the right shall have integer type, or the left operand shall have atomic, qualified, or unqualified arithmetic type, and the right shall have arithmetic type.
Change 6.5.16.2p2:
For the other operators, the left operand shall have atomic, qualified, or unqualified arithmetic type, and (considering the type the left operand would have after lvalue conversion) each operand shall have arithmetic type consistent with those allowed by the corresponding binary operator.
Change 6.7.3 para 5:
... If an attempt is made to refer to an object defined with a volatile-qualified type through use of an lvalue with non-volatile-qualified type, the behavior is undefined.132)
If an attempt is made to refer to an object defined with an _Atomic-qualified type through use of an lvalue with non-_Atomic-qualified type, the behavior is undefined.
Note: This statement was needed only because the aliasing rule otherwise allowed
such punning when _Atomic
was considered a qualifier. If atomic types
are just distinct types, this undefined behavior is implied by the type-based aliasing
rule.
There are several changes that go beyond what was intended by N1524; we recommend making these changes, but we present them separately so that the committee can make an informed choice:
Add a new section:
6.7.2.3 Atomic type specifiers
Constraints
The type name in an atomic type specifier shall not refer to an array type, a function type, an atomic type, or a qualified type. The type modified by the _Atomic qualifier shall not be an array type, a function type, an atomic type, or a qualified type.
Semantics
The properties associated with atomic types are meaningful only for expressions that are lvalues.
Note: It may be desirable to move some other statements about atomic types to this section as well.
Change 6.7.6.3p1:
A function declarator shall not specify a return type that is an atomic type,a function type, or an array type.
Change 6.7.6.3p4:
After adjustment, the parameters in a parameter type list in a function declarator that is part of a definition of that function shall not have incomplete type. The type in a parameter declaration shall not be an atomic type.
Change 6.9.1p6:
If the declarator includes an identifier list, each declaration in the declaration list shall have at least one declarator, those declarators shall declare only identifiers from the identifier list, no declaration in the declaration list shall declare an object with atomic type, and every identifier in the identifier list shall be declared. ...
To implement N1524 exactly as intended would require several more changes. Upon consideration, we recommend against these changes, but present them here so that the committee can make an informed choice:
Change 6.5.2.3p1:
The first operand of the . operator shall have an atomic, qualified, or unqualified structure or union type, and the second operand shall name a member of that type.
Change 6.5.2.3p2:
The first operand of the -> operator shall have type ''pointer to atomic, qualified, or unqualified structure'' or ''pointer to atomic, qualified, or unqualified union'', and the second operand shall name a member of the type pointed to.