ISO/IEC JTC1 SC22 WG14 N1447 - 2010-03-22
ISO/IEC JTC1 SC22 WG21 N3093 = 10-0083 - 2010-03-22
Lawrence Crowl, firstname.lastname@example.org, Lawrence@Crowl.org
Proposed Wording for C
6.2.8 Alignment of objects
6.7.5 Alignment specifier
7.1.2 Standard headers
Proposed Wording for C++
1.1 Scope [intro.scope]
2.12 Keywords [lex.key]
3.2 One definition rule [basic.def.odr]
3.11 Alignment [basic.align]
7.1 Specifiers [dcl.spec]
7.1.7 Alignment specifiers [dcl.align]
7.6.2 Alignment attribute [dcl.align]
220.127.116.11 Headers [headers]
18.1 General [support.general]
18.10 Other runtime support [support.runtime]
18.104.22.168 Other transformations [meta.trans.other]
D.5 C standard library headers [depr.c.headers]
The compatibility between the C and C++ alignment facilities is important to many members of the respective communities. This paper analyses the compatibility between the draft standards, WG14 N1425. and N3035, WG21 N3035. with respect to alignment.
This document presents what we believe to be the consensus proposal of the C and C++ compatibility mailing list. It incorporates detailed proposed wording for both standards.
Both languages have the same notion of
fundamental alignment (<=
extended alignment (>
Extended alignment support is implementation-defined in both languages.
Both languages intend to constrain the alignments to powers of two, but the wording to do so is confusing, and likely subject to misinterpretation. In particular, the 'weaker' constraint does not seem to be satisfiable unless the alignments are restricted to powers of two. Explicitly restricting alignment to powers of two would improve both languages.
Explicitly constrain alignments to powers of two.
Both C and C++ define an
These have compatible syntax and semantics:
Neither language provides an
alignof rule for expressions.
In both languages, the result is of type
and the results are meaningfully comparable.
It is in the declaration of alignment that C and C++ differ significantly.
C adds alignment-specifiers to its grammar.
The original C++ proposal did essentially the same, but with a different keyword.
However, the current C++ working draft uses attributes.
where the alignment attribute is one of:
and where the assignment-expression shall be an integral constant expression.
Spell the C1x keyword as "
and revert the C++ proposal to a keyword:
Introduce a system header,
that creates an identical spelling in both C and C++ for the keyword.
#define alignas _Alignas
#define __alignas_is_defined 1
Fortunately, C and C++ have very similar semantics for the effect of declaring alignment.
is defined as
Alignment to zero has no effect.
When multiple alignments are specified, the strictest takes effect.
It is unclear what happens when there are multiple alignments and one is zero. Does that one alignment have no effect, or is there no effect on the declaration?
If different translation units have different alignments, the behavior is undefined.
However, there are some differences.
Both C and C++ explicitly disallow alignment to less than the natural alignment. This facility is useful for accessing legacy binary files. However, relaxed alignments on pointers cause serious implementation problems for garbage-collected C++0x implementations. One potential compromise is to allow it for integers, but not for pointers.
C requires subsequent declarations to have the same or no alignment. C++ requires the non-defining declarations to have the same or no alignment. Always specifying alignment would be compatible in both languages, but not doing so only sometimes.
Define each individual alignment to zero to have no effect. That is, when there are multiple alignments specified, only alignments to zero have no effect.
A portable program cannot make use of relaxed alignment, so we propose that it remains disallowed in C and in C++.
Require that a definition or a tentative definition specifies the alignment; other declarations shall have the same alignment or no alignment.
C defines an
C++ appears to add nothing for aligned allocation,
though does leave some support implementation-defined.
Update the C++ working draft section 1.2 [intro.refs] to refer to the 2011 C standard. This date may need to change.
These edits are relative to working draft WG14 N1425.
to the list of headers for freestanding implementations
in paragraph 6.
to the list of forward references.
Edit paragraph 1 as follows.
Object types have alignment requirements which place restrictions on the addresses at which objects of that type may be allocated. An alignment is an implementation-defined integer value representing the number of bytes between successive addresses at which a given object can be allocated. An object type imposes an alignment requirement on every object of that type: stricter alignment can be requested using the
Edit paragraph 3 as follows.
extended alignmentis represented by an alignment greater than
alignof(max_align_t). It is implementation-defined whether any extended alignments are supported and the contexts in which they are supported. A type having an extended alignment requirement is an
over-alignedtype. [Footnote: It is intended that every valid alignment value is an integral power of two. —end footnote]
In paragraph 1,
In paragraph 1,
In paragraph 5,
Edit paragraph 6 as follows.
The alignment requirement of the declared object or field is taken to be the specified alignment. An alignment specification of zero has no effect. When multiple alignment specifiers occur in a declaration, the effective alignment requirement is the strictest specified alignment.
Edit paragraph 7 as follows.
If the definition of an object has an alignment specifier, any other declaration of that object shall either specify equivalent alignment or have no alignment specifier. If declarations of an object in different translation units have different alignment specifiers, the behavior is undefined.
to the list of standard headers
in paragraph 2.
Add a new section after
"7.17 Boolean type and values
Add a new paragraph 1 as follows.
Add a new paragraph 2 as follows.
Add a new paragraph 3 as follows.
In paragraph (6.4.1),
In paragraph (6.7.5),
Add a new section as follows.
The proposed wording mostly reverts the alignment specification to that of WG21 N2341, which was adopted in July 2007. These edits are relative to working draft WG21 N3035.
Edit paragraph 2 as follows. Note that this edit may need to be delayed until the C standard appears.
C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:
1999Programming languages — C (hereinafter referred to as the C standard ). In addition to the facilities provided by C, C++ provides additional data types, classes, templates, exceptions, name spaces, inline functions, operator overloading, function name overloading, references, free store management operators, and additional library facilities.
Add the keyword
before the keyword
Edit within paragraph 4 as follows.
the type T is the subject of an alignof expression (5.3.6) , or
Edit paragraph 1 as follows. Note the inserted comma.
Object types have
alignment requirements(3.9.1, 3.9.2) which place restrictions on the addressses at which an object of that type may be allocated. An aligmentis an implementation-defined integer value representing the number of bytes between successive addresses at which a given object can be allocated. An object type imposes an alignment requirement on every object of that type; stricter alignment can be requested using the alignment attribute (7.6.2).
Edit paragraph 4 as follows.
Alignments are represented as values of the type
std::size_t. Valid alignments include only those values returned by an
alignofexpression for the fundamental types plus an additional implementation-defined set of values which may be empty.
[Footnote: It is intended that every valid alignment value be an integral power of two. —end footnote]
Edit paragraph 1 as follows.
The specifiers that can be used in a declaration are
- decl-specifier-seqopt decl-specifier
Add a new section as follows. Editorially, this section might better appear after 7.1.2 Function specifiers [decl.fct.spec] in keeping with its position in the grammar.
Add paragraph 1 as follows.
Add paragraph 2 as follows.
Add paragraph 3 as follows.
Add paragraph 4 as follows.
Add paragraph 5 as follows.
Add paragraph 6 as follows.
Add paragraph 7 as follows.
Add paragraph 8 as follows.
Add paragraph 9 as follows.
Add paragraph 10 as follows.
Remove this section.
to "Table 14 — C++ headers for C library facilities".
to "Table 16 — Language support library summary"
under "18.10 Other runtime support".
Add a new table after
"Table 26 — Header
Table ?? — Header
Add a new paragraph after paragraph 6.
Edit table 51 as follows.
The value of default-alignment
shall be the most stringent alignment requirement for any C++ object type
whose size is no greater than
to "Table 144 — C headers".