Skip to content

Commit d0bd986

Browse files
committed
New issue from Jonathan: atomic_ref<cv T>::required_alignment should be the same as for T
1 parent 00b15bc commit d0bd986

File tree

1 file changed

+77
-0
lines changed

1 file changed

+77
-0
lines changed

xml/issue4453.xml

Lines changed: 77 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,77 @@
1+
<?xml version='1.0' encoding='utf-8' standalone='no'?>
2+
<!DOCTYPE issue SYSTEM "lwg-issue.dtd">
3+
4+
<issue num="4453" status="New">
5+
<title><tt>atomic_ref&lt;cv T&gt;::required_alignment</tt> should be the same as for `T`</title>
6+
<section><sref ref="[atomics.ref.ops]"/></section>
7+
<submitter>Jonathan Wakely</submitter>
8+
<date>06 Nov 2025</date>
9+
<priority>99</priority>
10+
11+
<discussion>
12+
<p>
13+
When <paper num="p3323r1"/> fixed support for <tt>atomic_ref&lt;cv T&gt;</tt>
14+
we didn't consider that an implementation could define `required_alignment`
15+
to be different from <tt>atomic_ref&lt;T&gt;::required_alignment</tt>.
16+
For example, a processor could support atomic loads on any `int` object,
17+
but could require a greater alignment for atomic stores (and read-modify-write
18+
and modify-write operations).
19+
So the `required_alignment` could be `alignof(int)` for `const int`
20+
but `2 * alignof(int)` for `int`, because the latter is needed for stores.
21+
</p>
22+
23+
<p>
24+
A malicious implementation could even define `required_alignment` to be
25+
greater for the `const T` specialization, which would make it undefined
26+
to use the new converting constructor added by <paper num="P3860R1"/>.
27+
</p>
28+
29+
<p>
30+
We should constrain implementations to use the same `required_alignment`
31+
for cv `T`, so that users can use <tt>atomic_ref&lt;const T&gt;</tt>
32+
on any object that is referenced by a <tt>atomic_ref&lt;T&gt;</tt>.
33+
</p>
34+
35+
</discussion>
36+
37+
<resolution>
38+
<p>
39+
This wording is relative to <paper num="N5014"/>.
40+
</p>
41+
42+
<ol>
43+
44+
<li><p>Modify <sref ref="[atomics.refs.ops]"/>, as indicated:</p>
45+
46+
<blockquote>
47+
<pre>
48+
static constexpr size_t required_alignment;
49+
</pre>
50+
<p>-1-
51+
The alignment required for an object to be referenced by an atomic reference,
52+
which is at least `alignof(T)`.
53+
<ins>
54+
The value of
55+
<tt>atomic_ref&lt;<i>cv</i> T&gt;::required_alignment</tt>
56+
is the same as
57+
<tt>atomic_ref&lt;T&gt;::required_alignment</tt>
58+
</ins>
59+
</p>
60+
<p> -2-
61+
[<i>Note 1</i>:
62+
Hardware could require an object referenced by an `atomic_ref`
63+
to have stricter alignment (<sref ref="[basic.align]"/>)
64+
than other objects of type `T`.
65+
Further, whether operations on an `atomic_ref` are lock-free
66+
could depend on the alignment of the referenced object.
67+
For example, lock-free operations on <code>std::complex&lt;double&gt;</code>
68+
could be supported only if aligned to `2*alignof(double)`.
69+
&mdash; <i>end note</i>]
70+
</p>
71+
</blockquote>
72+
</li>
73+
</ol>
74+
75+
</resolution>
76+
77+
</issue>

0 commit comments

Comments
 (0)