<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=US-ASCII">
<title>C and C++ Alignment Compatibility</title>
<style type="text/css">
td { vertical-align: top; }
</style>
</head>
<body>
<h1>C and C++ Alignment Compatibility</h1>

<p>
ISO/IEC JTC1 SC22 WG21 N3190 = 10-0180 - 2010-11-12
</p>

<p>
Lawrence Crowl (crowl@google.com, Lawrence@Crowl.org)
<br>
Daveed Vandevoorde (daveed@edg.com)
</p>

<p>
This paper revises
</p>
<blockquote><p>
ISO/IEC JTC1 SC22 WG21 N3093 = 10-0083 - 2010-03-22
</p></blockquote>
<p>
This revision
</p>
<ul>
<li>
removes edits to 1.1 [intro.scope] as being more appropriate to the editor;
</li>
<li>
corrects the alignment value restriction
to <em>non-negative</em> integral powers of two.
</li>
<li>
adjusts the alignment specifier syntax
for proper reference as a parameter pack expansion;
</li>
<li>
and makes other minor editorial changes.
</li>
</ul>
<p>
This revision has no effect on C compatibility.
</p>

<p>
<a href="#Introduction">Introduction</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#Fundamental">Fundamental Alignment</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Proposal<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#Operator">Alignof Operator</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#Declaring">Declaring Alignment</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Proposal<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#Semantics">Alignment Semantics</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Proposal<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#Allocation">Aligned Allocation</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Proposal<br>
<a href="#WordingCPP">Proposed Wording for C++</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#lex.key">2.12 Keywords [lex.key]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#basic.align">3.11 Alignment [basic.align]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#dcl.attr.grammar">7.6.1 Attribute syntax and semantics [dcl.attr.grammar]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#dcl.align">7.6.2 Alignment <del>attribute</del> <ins>specifier</ins> [dcl.align]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#variadic">14.5.3 Variadic templates [temp.variadic]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#headers">17.6.1.2 Headers [headers]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#support.general">18.1 General [support.general]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#support.runtime">18.10 Other runtime support [support.runtime]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#meta.trans.other">20.7.6.6 Other transformations [meta.trans.other]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#depr.c.headers">D.5 C standard library headers [depr.c.headers]</a><br>
</p>


<h2><a name="Introduction">Introduction</a></h2>

<p>
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
<a href="http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1425.pdf">N1425</a>.
and N3035,
WG21
<a href="../../papers/2010/n3035.pdf">N3035</a>.
with respect to alignment.
</p>

<p>
This document presents C++-specific edits to
what we believe to be the consensus proposal
of the C and C++ compatibility mailing list.
It incorporates revised wording for the C++ standards.
We believe that no wording change is required for C
and that full compatiblity has been maintained.
</p>

<p>
This document addresses national body comments
GB 31 and (more generally) US 1.
</p>


<h3><a name="Fundamental">Fundamental Alignment</a></h3>

<p>
Both languages have the same notion of
fundamental alignment (&lt;=&nbsp;<code>alignof(max_align_t)</code>) and
extended alignment (&gt;&nbsp;<code>alignof(max_align_t)</code>).
Extended alignment support is implementation-defined in both languages.
</p>

<p>
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.
</p>


<h4>Proposal</h4>

<p>
Explicitly constrain alignments to powers of two.
</p>


<h3><a name="Operator">Alignof Operator</a></h3>

<p>
Both C and C++ define an <code>alignof</code> operator.
These have compatible syntax and semantics:
</p>

<dl>
<dt><var>unary-expression:</var></dt>
<dd><code>alignof (</code> <var>type-name/id</var> <code>)</code></dd>
</dl>

<p>
Neither language provides an <code>alignof</code> rule for expressions.
</p>

<dl>
<dt><var>unary-expression:</var></dt>
<dd><code>alignof </code> <var>unary-expression</var></dd>
</dl>

<p>
In both languages, the result is of type <code>size_t</code>,
and the results are meaningfully comparable.
</p>


<h3><a name="Declaring">Declaring Alignment</a></h3>

<p>
It is in the declaration of alignment
that C and C++ differ significantly.
</p>

<p>
C adds alignment-specifiers to its grammar.
</p>

<dl>
<dt><var>declaration-specifiers:</var></dt>
<dd><var>alignment-specifier declaration-specifiers<sub>opt</sub></var></dd>
<dt><var>alignment-specifier:</var></dt>
<dd><code>_Align (</code> <var>type-name</var> <code>)</code></dd>
<dd><code>_Align (</code> <var>constant-expression</var> <code>)</code></dd>
</dl>

<p>
The original C++ proposal did essentially the same,
but with a different keyword.
</p>

<dl>
<dt><var>decl-specifier:</var></dt>
<dd><var>alignment-specifier</var></dd>
<dt><var>alignment-specifier:</var></dt>
<dd><code>alignas (</code> <var>type-id</var> <code>)</code></dd>
<dd><code>alignas (</code> <var>constant-expression</var> <code>)</code></dd>
</dl>

<p>
However,
the current C++ working draft uses attributes.
</p>

<dl>
<dt><var>simple-declaration:</var></dt>
<dd><var>attribute-specifier<sub>opt</sub>
	declaration-specifiers<sub>opt</sub>
	attribute-specifier<sub>opt</sub>
	init-declarator-list<sub>opt</sub></var>
	<code>;</code></dd>
</dl>

<p>
where the alignment attribute is one of:
</p>

<dl>
<dt><var>attribute:</var></dt>
<dd><code>align (</code> <var>type-name</var> <code>)</code></dd>
<dd><code>align (</code> <var>assignment-expression</var> <code>)</code></dd>
</dl>

<p>
and where the <var>assignment-expression</var>
shall be an integral constant expression.
</p>


<h4>Proposal</h4>

<p>
Spell the C1x keyword as "<code>_Alignas</code>",
and revert the C++ proposal to a keyword,
but syntactically in the position of attributes.
</p>

<dl>
<dt><var>attribute-specifier:</var></dt>
<dd><var>alignment-specifier</var></dd>
<dt><var>alignment-specifier:</var></dt>
<dd><code>alignas (</code> <var>type-id</var> <code>)
...</code><var><sub>opt</sub></var></dd>
<dd><code>alignas (</code> <var>constant-expression</var> <code>)
...</code><var><sub>opt</sub></var></dd>
</dl>

<p>
Introduce a system header, <code>&lt;stdalign.h&gt;</code>,
analagous to <code>&lt;stdbool.h&gt;</code>,
that creates an identical spelling in both C and C++ for the keyword.
Example:
</p>

<p><code>
#ifndef __cplusplus
<br>
#define alignas _Alignas
<br>
#define __alignas_is_defined 1
<br>
#endif
</code></p>


<h3><a name="Semantics">Alignment Semantics</a></h3>

<p>
Fortunately,
C and C++ have very similar semantics for the effect of declaring alignment.
</p>

<ul>
<li><p>
Type alignment, <code>make_align(</code><var>type</var><code>)</code>,
is defined as <code>make_align(alignof(</code><var>type</var><code>))</code>.
</p></li>

<li><p>
Alignment to zero has no effect.
</p></li>

<li><p>
When multiple alignments are specified, the strictest takes effect.
</p></li>

<li><p>
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?
</p></li>

<li><p>
If different translation units have different alignments,
the behavior is undefined.
</p></li>

</ul>

<p>
However, there are some differences.
</p>

<ul>

<li><p>
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.
</p></li>

<li><p>
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.
</p></li>

</ul>


<h4>Proposal</h4>

<p>
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.
</p>

<p>
A portable program cannot make use of relaxed alignment,
so we propose that it remains disallowed in C and in C++. 
</p>

<p>
Require that a definition or a tentative definition specifies the alignment;
other declarations shall have the same alignment or no alignment.
</p>


<h3><a name="Allocation">Aligned Allocation</a></h3>

<p>
C defines an <code>aligned_alloc</code> function.
C++ appears to add nothing for aligned allocation,
though does leave some support implementation-defined.
</p>


<h4>Proposal</h4>

<p>
Defer this issue to the editor.
</p>


<h2><a name="WordingCPP">Proposed Wording for C++</a></h2>

<p>
These edits are relative to working draft WG21
<a href="../../papers/2010/n3092.pdf">N3092</a>.
</p>

<p>
<b>Note to the editor</b>: Replace every occurrence of <var>attribute-specifier</var>
with <var>attribute-specifier-seq</var> throughout the working draft
except in 7.6.1 paragraphs 1, 3, and 6
(but <em>including</em> paragraph 4).
</p>

<h3><a name="lex.key">2.12 Keywords [lex.key]</a></h3>

<p>
Add the keyword <code>alignas</code>
before the keyword <code>alignof</code>.
</p>


<h3><a name="basic.align">3.11 Alignment [basic.align]</a></h3>

<p>
Edit paragraph 1 as follows.
</p>

<blockquote><p>
Object types have <dfn>alignment requirements</dfn> (3.9.1, 3.9.2)
which place restrictions on the addresses
at which an object of that type may be allocated.
An <dfn>alignment</dfn> 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 <del>alignment attribute (7.6.2)</del>
<ins>alignment specifier ([dcl.align])</ins>.
</p></blockquote>

<p>
Edit paragraph 4 as follows.
Note the inserted comma.
</p>

<blockquote>
<p>
Alignments are represented as values of the type <code>std::size_t</code>.
Valid alignments include only those values
returned by an <code>alignof</code> expression
for the fundamental types
plus an additional implementation-defined set of values<ins>,</ins>
which may be empty.
<del>
[<i>Footnote:</i>
It is intended that every valid alignment value be an integral power of two.
&mdash;<i>end footnote</i>]
</del>
<ins>
Every alignment value shall be a non-negative integral power of two.
</ins>
</p>
</blockquote>


<h3><a name="dcl.attr.grammar">7.6.1 Attribute syntax and semantics [dcl.attr.grammar]</a></h3>

<p>
Within paragraph 1, edit as follows:
</p>

<blockquote>
<dl>
<dt><ins><var>attribute-specifier-seq:</var></ins></dt>
<dd><ins><var>attribute-specifier-seq<sub>opt</sub> attribute-specifier</var></ins></dd>
<dt><var>attribute-specifier:</var></dt>
<dd><code>[ [</code> <var>attribute-list</var> <code>] ]</code></dd>
<dd><ins><var>alignment-specifier</var></ins></dd>
<dt><ins><var>alignment-specifier:</var></ins></dt>
<dd><ins><code>alignas (</code> <var>type-id</var>
<code>...</code><var><sub>opt</sub></var><code>)</code></ins></dd>
<dd><ins><code>alignas (</code> <var>alignment-expression</var>
<code>...</code><var><sub>opt</sub></var><code>)</code></ins></dd>
</dl>
</blockquote>


<h3><a name="dcl.align">7.6.2 Alignment <del>attribute</del> <ins>specifier</ins> [dcl.align]</a></h3>

<p>
Edit the section heading as above.
</p>

<p>
Edit paragraph 1 as follows.
Note that CWG 1036 also edits this paragraph.
We see no semantic conflict.
</p>

<blockquote>
<p>
<del>
The <var>attribute-token</var> <code>align</code> specifies alignment (3.11).
The <var>attribute</var> shall have one of the following forms:
</del>
</p>
<blockquote>
<p>
<del>
<code>align (</code> <var>type-id</var> <code>)</code><br>
<code>align (</code> <var>assignment-expression</var> <code>)</code>
</del>
</p>
</blockquote>
<p>
<del>
The <var>attribute</var>
may be followed by an ellipsis.
</del>
<del>The <var>attribute</var></del>
<ins>An <var>alignment-specifier</var></ins>
may be applied to a variable
that is neither a function parameter
nor declared with the <del>register</del>
<ins><code>register</code></ins> storage class specifier
and to a class data member that is not a bit-field.
<del>The <var>attribute</var></del>
<ins>An <var>alignment-specifier</var></ins>
may also be applied to the declaration of a class or enumeration type.  
<ins>
An <var>alignment-specifier</var> with an ellipsis
is a pack expansion ([temp.variadic]).
</ins>
</p>
</blockquote>

<p>
Edit within paragraph 2 as follows.
</p>

<blockquote>
<p>
When the <del>alignment attribute</del>
<ins><var>alignment-specifier</var></ins>
is of the form
<code>align<ins>as</ins> (</code>
<var>assignment-expression</var> <code>)</code>:
</p>
</blockquote>

<p>
Edit paragraph 3 as follows.
</p>

<blockquote>
<p>
When the <del>alignment attribute</del>
<ins><var>alignment-specifier</var></ins>
is of the form
<code>align<ins>as</ins>(</code> <var>type-id</var><code>)</code>,
it shall have the same effect as
<code>align<ins>as</ins>(alignof(</code><var>type-id</var><code>))</code>
([expr.alignof]).
</p>
</blockquote>

<p>
Edit paragraph 4 as follows.
</p>

<blockquote>
<p>
When multiple <del>alignment attributes</del>
<ins><var>alignment-specifier</var>s</ins> are specified for an object,
the alignment requirement shall be set to the strictest specified alignment.
</p>
</blockquote>

<p>
Edit paragraph 5 as follows.
</p>

<blockquote>
<p>
The combined effect of all <del>alignment attributes</del>
<ins><var>alignment-specifier</var>s</ins> in a declaration
shall not specify an alignment
that is less strict than the alignment
that would otherwise be required for the object being declared.
</p>
</blockquote>

<p>
Edit paragraph 6 as follows.
</p>

<blockquote>
<p>
If the defining declaration of an entity
has an <del>alignment attribute</del>
<ins><var>alignment-specifier</var></ins>,
any non-defining declaration of that entity
shall either specify equivalent alignment or
have no <del>alignment attribute</del>
<ins><var>alignment-specifier</var></ins>.
Conversely, if any declaration of an entity
has an <del>alignment attribute</del>
<ins><var>alignment-specifier</var></ins>,
every defining declaration of that entity
shall specify an equivalent alignment.
No diagnostic is required
if declarations of an entity have different
<del>alignment attribute</del>
<ins><var>alignment-specifier</var>s</ins>
in different translation units.
</p>
<p>
[<i>Example:</i>
</p>
<blockquote><pre><code>
// <i>Translation unit #1:</i>
struct S { int x; } s, p = &amp;s;
// <i>Translation unit #2:</i>
<del>struct [[align(16)]] S; // <i>error: definition of S lacks alignment; no</i></del>
<ins>struct alignas(16) S;   // <i>error: definition of S lacks alignment; no</i></ins>
extern S* p;                 // <i>diagnostic required</i>
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
</p>
</blockquote>

<p>
Edit paragraph 7 as follows.
</p>

<blockquote>
<p>
[<i>Example:</i>
An aligned buffer with an alignment requirement of <code>A</code>
and holding <code>N</code> elements of type <code>T</code>
other than <code>char</code>, <code>signed char</code>,
or <code>unsigned char</code> can be declared as:
</p>
<blockquote><pre><code>
<del>T buffer [[ align(T), align(A) ]] [N];</del>
<ins>alignas(T) alignas(A) T buffer[N];</ins>
</code></pre></blockquote>
<p>
Specifying
<del><code>align(T)</code> in the <var>attribute-list</var></del>
<ins><code>alignas(T)</code></ins> ensures that
the final requested alignment will not be weaker than <code>alignof(T)</code>,
and therefore the program will not be ill-formed.
&mdash;<i>end example</i>]
</p>
</blockquote>

<p>
Edit paragraph 8 as follows.
</p>

<blockquote>
<p>
[<i>Example:</i>
</p>
<blockquote><pre><code>
<del>void f [[ align(double) ]] (); // error: alignment applied to function</del>
<ins>alignas(double) void f(); // error: alignment applied to function</ins>
<del>unsigned char c
   [[ align(double) ]] [sizeof(double)];</del>
<ins>alignas(double) unsigned char c[sizeof(double)];</ins>
            // array of characters, suitably aligned for a double
extern unsigned char c[sizeof(double)];
            // no alignas necessary
<del>extern unsigned char c
   [[ align(float) ]] [sizeof(double)];</del>
<ins>alignas(float) extern unsigned char c[sizeof(double)];</ins>
            // error: different alignment in declaration
</code></pre></blockquote>
<p>
&mdash;<i>end example</i>]
</p>
</blockquote>


<h3><a name="variadic">14.5.3 Variadic templates [temp.variadic]</a></h3>

<p>
Edit within paragraph 4 as follows.
</p>

<blockquote>
<ul>
<li>....</li>
<li>In an <var>attribute-list</var> (7.6.1);
the patttern is an <var>attribute</var>.</li>
<li><ins>In an <var>alignment-specifier</var> (7.6.2);
the pattern is the <var>alignment-specifier</var>
without the ellipsis.</ins></li>
<li>....</li>
</ul>
</blockquote>

<p>
Edit paragraph 6 as follows.
</p>
<blockquote>
<p>
The instantiation of an expansion produces a list
E<sub>1</sub> O E<sub>2</sub> O ... O E<sub><var>N</var></sub>,
where <var>N</var> is the number of elements
in the pack expansion parameters
and O is the syntactically-appropriate separator for the list
<ins>(if any)</ins>.
Each E<sub><var>i</var></sub> is generated
by instantiating the pattern and
replacing each pack expansion parameter with its ith element.
All of the E<sub><var>i</var></sub> become elements in the enclosing list.
[<i>Note:</i>
The variety of list varies with the context:
<var>expression-list</var>, <var>base-specifier-list</var>,
<var>template-argument-list</var>, etc.
&mdash;<i>end note</i>]
</p>
</blockquote>


<h3><a name="headers">17.6.1.2 Headers [headers]</a></h3>

<p>
Add <code>&lt;cstdalign&gt;</code>
to "Table 14 &mdash; C++ headers for C library facilities".
</p>


<h3><a name="support.general">18.1 General [support.general]</a></h3>

<p>
Add <code>&lt;cstdalign&gt;</code>
to "Table 16 &mdash; Language support library summary"
under "18.10 Other runtime support".
</p>


<h3><a name="support.runtime">18.10 Other runtime support [support.runtime]</a></h3>

<p>
Add a new table after
"Table 26 &mdash; Header <code>&lt;cstdbool&gt;</code> synopsis".
</p>

<blockquote>
<table border=1>
<caption>Table ?? &mdash;
Header <code>&lt;cstdalign&gt;</code> synopsis".</caption>
<thead>
<tr>
<th><ins>Type</ins></th>
<th><ins>Names(s)</ins></th>
</tr>
</thead>
<tbody>
<tr>
<th><ins>Macro:</ins></th>
<td><ins><code>__alignas_is_defined</code></ins></td>
</tr>
</tbody>
</table>
</blockquote>

<p>
Add a new paragraph after paragraph 6.
</p>

<blockquote>
<p>
<ins>The header <code>&lt;cstdalign&gt;</code>
and the header <code>&lt;stdalign.h&gt;</code>
shall not define a macro named <code>alignas</code>.</ins>
</p>
</blockquote>


<h3><a name="meta.trans.other">20.7.6.6 Other transformations [meta.trans.other]</a></h3>

<p>
Edit within table 53 as follows.
</p>

<table border=1>
<caption>Table 53 &mdash; Other transformations</caption>
<thead>
<tr><th>Template</th><th>Condition</th><th>Comments</th></tr>
</thead>
<tbody>
<tr>
<td>
<code>template &lt; std::size_t Len,
std::size_t Align =</code> <var>default-alignment</var><code>&gt;
struct aligned_storage;</code>
</td>
<td>
<code>Len</code> shall not be zero.
<code>Align</code> shall be equal to <code>alignof&lt;T&gt;</code>
for some type <code>T</code> or to <var>default-alignment</var>.
</td>
<td>
The value of <var>default-alignment</var>
shall be the most stringent alignment requirement for any C++ object type
whose size is no greater than <code>Len</code> (3.9).
The member typedef <code>type</code>
shall be a POD type
suitable for use as uninitialized storage for any object
whose size is at most <code>Len</code>
and whose alignment is a divisor of <code>Align</code>.
</td>
</tr>
<tr>
<td>
<ins><code>template &lt; std::size_t Len, class ... Types &gt;
struct aligned_union;</code></ins>
</td>
<td>
<ins>At least one type is provided.</ins>
</td>
<td>
<ins>The member typedef <code>type</code>
shall be a POD type
suitable for use as uninitialized storage for any object
whose type is listed in <code>Types</code>;
its size shall be at least <code>Len</code>.
The static member <code>alignment_value</code>
shall be an integral constant of type <code>std::size_t</code>
whose value is the strictest alignment of all types
listed in <code>Types</code>.</ins>
</td>
</tr>
<tr>
<td>...</td>
<td>...</td>
<td>...</td>
</tr>
</tbody>
</table>

<p>
Edit paragraph 1 as follows.
</p>

<blockquote>
<p>
[<i>Note:</i>
A typical implementation would define aligned_storage as:
</p>
<blockquote><pre><code>
template &lt;std::size_t Len, std::size_t Alignment&gt;
struct aligned_storage {
  typedef struct {
     <del>unsigned char __data [[ align(Alignment) ]] [Len];</del>
     <ins>alignas(Alignment) unsigned char __data[Len];</ins>
  } type;
};
</code></pre></blockquote>
<p>
&mdash;<i>end note</i>]
</p>
</blockquote>


<h3><a name="depr.c.headers">D.5 C standard library headers [depr.c.headers]</a></h3>

<p>
Add <code>&lt;stdalign.h&gt;</code>
to "Table 144 &mdash; C headers".
</p>

</body>
</html>
