<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<style type="text/css">/*<![CDATA[*/

body { color: #000000; background-color: #FFFFFF; }
del { text-decoration: line-through; color: #8B0040; }
ins { text-decoration: underline; color: #005100; }

p.example { margin-left: 2em; }
pre.example { margin-left: 2em; }
div.example { margin-left: 2em; }

code.extract { background-color: #F5F6A2; }
pre.extract { margin-left: 2em; background-color: #F5F6A2;
  border: 1px solid #E1E28E; }

p.function { }
.attribute { margin-left: 2em; }
.attribute dt { float: left; font-style: italic;
  padding-right: 1ex; }
.attribute dd { margin-left: 0em; }

blockquote.std { color: #000000; background-color: #F1F1F1;
  border: 1px solid #D1D1D1;
  padding-left: 0.5em; padding-right: 0.5em; }
blockquote.stddel { text-decoration: line-through;
  color: #000000; background-color: #FFEBFF;
  border: 1px solid #ECD7EC;
  padding-left: 0.5empadding-right: 0.5em; ; }

blockquote.stdins { text-decoration: underline;
  color: #000000; background-color: #C8FFC8;
  border: 1px solid #B3EBB3; padding: 0.5em; }

blockquote pre em { font-family: normal }

table { border: 1px solid black; border-spacing: 0px;
  margin-left: auto; margin-right: auto; }
th { text-align: left; vertical-align: top;
  padding-left: 0.8em; border: none; }
td { text-align: left; vertical-align: top;
  padding-left: 0.8em; border: none; }

/*]]>*/
</style>

<title>Pointer safety and placement new</title>
</head>
<body>

<p style="text-align: right; float: right">
ISO/IEC JTC1 SC22 WG21<br />
N4303<br />
Richard Smith, richard@metafoo.co.uk<br />
Hubert Tong, hstong@ca.ibm.com<br />
2014-11-21
</p>

<h1>Pointer safety and placement new</h1>

<h2><a id="Abstract">Abstract</a></h2>
<p>This paper describes a usage pattern that occurs with the reserved placement forms of <code>operator new</code> (§18.6.1.3 [new.delete.placement]) which was not supported by the Standard until C++14.
It provides reasoning for why the pattern is harmful and it suggests a mechanism to be used where the difficultly of converting is a plain syntactic transformation.</p>

<h2><a id="ProblemDesc">Problem description</a></h2>
<p>The reserved placement forms of <code>operator new</code> (hereafter referred to as <i>placement new functions</i>) are intended to facilitate constructing an object at a known address.</p>

<p>Whereas it is plainly obvious that it is not possible to reliably refer to the memory allocated by allocation functions other than placement new functions without using the value returned by the allocation function,
it <i>is</i> possible for placement new functions.</p>

<p>Users take advantage of this apparent possibility by referring to the new object through pointer values obtained from casting a pointer to the object which originally held the storage.</p>

<p>Consider:</p>
<pre class="example"
>#include &lt;new&gt;
#include &lt;cassert&gt;

struct A { char buf[1]; };
struct B { char buf[1]; };

int main(void) {
    A a{ { 0 } };
    B *bp = static_cast&lt;B *&gt;(static_cast&lt;void *&gt;(&amp;a));
    new (bp) B{ { 1 } };
    assert(bp-&gt;buf[0] == 1);
}</pre>

<p>Prior to the adoption of the resolution for DR 1412 [<a href="#CWG1412">CWG1412</a>], the value of <code>bp</code> is unspecified at the point of its initialization and its subsequent passing to <code>operator new</code> via the <i>new-expression</i>.
Said pointer may be null, insufficiently aligned or otherwise dangerous to use. [<a href="#Note_1">1</a>]</p>

<p>The resolution to DR 1412 modifies the specification of <code>static_cast</code> such that the cast now reliably points to the start of the memory associated with <code>a</code>.
Unfortunately this allows placement new to foul analyses which use address value propagation to refine aliasing based on knowing where the pointer points.
In the example above, such an optimization may find that the address of <code>bp-&gt;buf[0]</code> to be associated with the object <code>a</code>.
From that finding, the optimizer may then decide that accesses to the memory ought to be done through a glvalue which may access the stored value of <code>a</code> without invoking undefined behavior (§3.10 [basic.lval]).
The initialization done via the <i>new-expression</i> is not such an access.</p>

<p>In addition to the above, CWG 1776 [<a href="#CWG1776">CWG1776</a>] was opened because a language requirement exists which enables optimization but makes it difficult to implement <code>std::optional</code>.
As mentioned in [<a href="#_1776ref1">1776ref1</a>], the difficultly can be resolved by having a constexpr mechanism which sanitizes pointer values.
The proposed solution below provides such a mechanism.</p>

<h2><a id="Proposal">Proposed solution</a></h2>
<p>A mechanism is proposed which provides an interface that takes a pointer to a specific type and returns a pointer value which points to the object of that type (ignoring cv-qualification) located at that memory.
The intention is that this mechanism will be taken by a compiler to be opaque to address value propagation analysis as appropriate.</p>

<p>Add to §18.6 [support.dynamic] paragraph 1:</p>
<blockquote class="stdins"><pre
>namespace std {
  template &lt;typename T&gt;
    constexpr T* launder(T* p) noexcept;
}</pre></blockquote>

<p>Add a new subclause under §18.6 [support.dynamic]:</p>
<blockquote class="stdins">
<dl><dt><code>template &lt;typename T&gt; constexpr T* launder(T* p) noexcept;</code></dt>
<dd><p><i>Required behavior:</i> An invocation of this function may be used in core constant expressions whenever the value of its argument may be used in a core constant expression.</p>

<p><i>Requires:</i> <code>p</code> represents the address <code>A</code> of a byte in memory and an object <code>Obj</code> whose cv-unqualified type is <code>remove_cv_t&lt;T&gt;</code> is located at the address <code>A</code>.</p>

<p><i>Returns:</i> A value of type <code>T *</code> which points to <code>Obj</code>.</p></dd></dl></blockquote>

<h2><a id="Attributions">Attributions</a></h2>
<p>The authors thank Gabriel Dos Reis, chair of SG12 for providing time to discuss the concerns described herein during the SG12 working session.
The authors would also like to thank Chris Bowler of IBM Canada and any others who may have been unintentionally missed for their valuable input and feedback on this paper.</p>

<h2><a id="Notes">Notes</a></h2>
<p>[<a id="Note_1">1</a>] This calls attention to the fact that the placement new functions cannot be implemented such that they satisfy both the constraint in §3.7.4 [basic.stc.dynamic] and the requirements of §18.6.1.3 [new.delete.placement].
The forthcoming resolution for CWG 1910 [<a href="#CWG1910">CWG1910</a>] is expected to handle this issue.</p>

<h2><a id="References">References</a></h2>
<p>[<a id="CWG1412">CWG1412</a>] Problems in specifying pointer conversions<br />
[<a id="CWG1776">CWG1776</a>] Replacement of class objects containing reference members<br />
[<a id="CWG1910">CWG1910</a>] “Shall” requirement applied to runtime behavior<br />
[<a id="_1776ref1">1776ref1</a>] Implementability of <code>std::optional</code>,
<a href="https://groups.google.com/a/isocpp.org/d/msg/std-proposals/93ebFsxCjvQ/Q5LUnO8339wJ">https://groups.google.com/a/isocpp.org/d/msg/std-proposals/93ebFsxCjvQ/Q5LUnO8339wJ</a></p>
</body>
</html>
