<!DOCTYPE html>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
<html>
<style type="text/css">
  ins, ins * { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  del, del * { text-decoration:line-through; background-color:#FFA0A0 }
  #hidedel:checked ~ * del, #hidedel:checked ~ * del * { display:none; visibility:hidden }

blockquote {
  padding: .5em;
  border: .5em;
  border-color: silver;
  border-left-style: solid;
}

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

p.grammarlhs { margin-bottom: 0 }
p.grammarrhs { margin-left:8em; margin-top:0; margin-bottom:0; text-indent:-4em }

div.wrapper {
    max-width: 60em;
    margin: auto;
}

a { text-decoration: none; }

a.hidden_link {
    text-decoration: none;
    color: inherit;
}

li {
    margin-top: 0.0em;
    margin-bottom: 0.0em;
}

h1 { line-height: 1; }
h2 { line-height: 1; }
h3 { line-height: 1; }
h4 { line-height: 1; }

:target { background-color: #C9FBC9; }
:target .codeblock { background-color: #C9FBC9; }
:target ul { background-color: #C9FBC9; }

.abbr_ref { float: right; }

.folded_abbr_ref { float: right; }
:target .folded_abbr_ref { display: none; }

:target .unfolded_abbr_ref { float: right; display: inherit; }
.unfolded_abbr_ref { display: none; }

.secnum { display: inline-block; min-width: 35pt; }
.annexnum { display: block; }

div.sourceLinkParent {
    float: right;
}

a.sourceLink {
    position: absolute;
    opacity: 0;
    margin-left: 10pt;
}

a.sourceLink:hover {
    opacity: 1;
}

div.marginalizedparent {
    position: relative;
    left: -5em;
}

div.footnoteNumberParent {
    position: relative;
    left: -4.7em;
}

a.marginalized {
    position: absolute;
    font-size: 75%;
    text-align: right;
    width: 5em;
}

a.enumerated_item_num {
    position: relative;
    left: -3.5em;
    display: inline-block;
    margin-right: -3em;
    text-align: right;
    width: 3em;
}

div.para { margin-bottom: 0.6em; margin-top: 0.6em; text-align: justify; }
div.section { text-align: justify; }
div.sentence { display: inline; }

span.indexparent {
    display: inline;
    position: relative;
    float: right;
    right: -1em;
}

a.index {
    position: absolute;
    display: none;
}

a.index:before { content: "âŸµ"; }
    /* this way the content is not selectable */

a.index:target {
    display: inline;
}

.indexitems {
    margin-left: 2em;
    text-indent: -2em;
}

div.itemdescr {
    margin-left: 3em;
}

.bnf {
    font-family: serif;
    margin-left: 40pt;
    margin-top: 0.5em;
    margin-bottom: 0.5em;
}

.ncbnf {
    font-family: serif;
    margin-top: 0.5em;
    margin-bottom: 0.5em;
    margin-left: 40pt;
}

.bnftab {
    font-family: serif;
    font-style: italic;
    margin-left: 40pt;
    margin-top: 0.5em;
    margin-bottom: 0.5em;
}

.ncsimplebnf {
    font-family: serif;
    font-style: italic;
    margin-top: 0.5em;
    margin-bottom: 0.5em;
    margin-left: 40pt;
}

.ncbnftab {
    font-family: serif;
    font-style: italic;
    margin-top: 0.5em;
    margin-bottom: 0.5em;
    margin-left: 40pt;
}

.bnfkeywordtab {
    margin-top: 0.5em;
    margin-bottom: 0.5em;
    margin-left: 40pt;
}

span.textnormal {
    font-style: normal;
    font-family: serif;
    white-space: normal;
    display: inline-block;
}

span.descr { font-style: normal; font-family: serif; }
span.grammarterm { font-style: italic; }
span.term { font-style: italic; }
span.terminal { font-family: monospace; font-style: normal; }
span.nonterminal { font-style: italic; }
span.tcode { font-family: monospace; font-style: normal; }
span.textbf { font-weight: bold; }
span.textsc { font-variant: small-caps; }
a.nontermdef { font-style: italic; font-family: serif; }
span.emph { font-style: italic; }
span.techterm { font-style: italic; }
span.mathit { font-style: italic; }
span.mathsf { font-family: sans-serif; }
span.mathrm { font-family: serif; font-style: normal; }
span.textrm { font-family: serif; }
span.textsl { font-style: italic; }
span.mathtt { font-family: monospace; font-style: normal; }
span.mbox { font-family: serif; font-style: normal; }
span.ungap { display: inline-block; width: 2pt; }
span.textit { font-style: italic; }
span.texttt { font-family: monospace; }
span.tcode_in_codeblock { font-family: monospace; font-style: normal; }

span.phantom { color: white; }
span.math { }

span.mathblock {
    display: block;
    margin-left: auto;
    margin-right: auto;
    margin-top: 1.2em;
    margin-bottom: 1.2em;
    text-align: center;
}

span.mathalpha {
    font-style: italic;
}

span.synopsis {
    font-weight: bold;
    margin-top: 0.5em;
    display: block;
}

span.definition {
    font-weight: bold;
    display: block;
}

.codeblock {
    margin-left: 1.2em;
    line-height: 127%;
}

code {
    font-family: monospace;
    font-style: normal;
}

code.itemdecl {
    margin-top: 2ex;
    white-space: pre;
    display: block;
}

.comment {
    font-style: italic;
    font-family: serif;
}

span.textsuperscript {
    vertical-align: super;
    font-size: smaller;
    line-height: 0;
}

.footnotenum { vertical-align: super; font-size: smaller; line-height: 0; }

.footnote {
    font-size: small;
    margin-left: 2em;
    margin-right: 2em;
    margin-top: 0.6em;
    margin-bottom: 0.6em;
}

div.minipage {
    display: inline-block;
    margin-right: 3em;
}

div.numberedTable {
    text-align: center;
    margin: 2em;
}

div.figure {
    text-align: center;
    margin: 2em;
}

table {
    border: 1px solid black;
    border-collapse: collapse;
    margin-left: auto;
    margin-right: auto;
    margin-top: 0.8em;
    text-align: left;
    hyphens: none; /* otherwise some columns get very narrow, e.g. [tab:hash] */
}

td, th {
    padding-left: 1em;
    padding-right: 1em;
    vertical-align: top;
}

td.left {
    text-align: left;
}

td.right {
    text-align: right;
}

td.center {
    text-align: center;
}

td.justify {
    text-align: justify;
}

td.border {
    border-left: 1px solid black;
}

tr.rowsep, td.cline {
    border-top: 1px solid black;
}

tr.capsep {
    border-top: 3px solid black;
    border-top-style: double;
}

th {
    border-bottom: 1px solid black;
}

span.centry {
    font-weight: bold;
}

div.table {
    display: block;
    margin-left: auto;
    margin-right: auto;
    text-align: center;
    width: 90%;
}

span.indented {
    display: block;
    margin-left: 2em;
    margin-bottom: 1em;
    margin-top: 1em;
}
</style>

<title>P1642R6 Freestanding Library: Easy [utilities], [ranges], and [iterators]</title>
<body>
<h1>Freestanding Library: Easy [utilities], [ranges], and [iterators]</h1>
Document number: P1642R6<br/>
Date: 2021-05-30<br/>
Reply-to: Ben Craig &lt;ben dot craig at gmail dot com&gt;<br/>
Audience: Library Evolution Working Group
<h1>Change history</h1>
<h3> R6 </h3>
<ul>
  <li>Adding the accidentally omitted <code>addressof</code>.  Earlier versions of the paper included it, and it was lost due to shifts in this paper's wording, and the relocation of <code>addressof</code> out of <a href="https://wg21.link/specialized.algorithms">[specialized.algorithms]</a></li>
</ul>
<h3> R5 </h3>
<ul>
  <li>Rebasing to N4868</li>
  <li>Adding <code>_Exit</code>, as <code>quick_exit</code> is specified in terms of <code>_Exit</code></li>
  <li>Explicitly listing out the algorithms from <a href="https://wg21.link/specialized.algorithms">[specialized.algorithms]</a> instead of referring to them by the stable name tag</li>
</ul>
<h3> R4 </h3>
<ul>
  <li>Moved feature test macros to <a href="https://wg21.link/P2198">P2198</a></li>
  <li>Pulled in wording approach from <a href="https://wg21.link/P1641">P1641</a>.  Abandoning the P1641 paper number</li>
  <li>Adding <code>make_obj_using_allocator</code> and <code>uninitialized_construct_using_allocator</code>.  These do not allocate memory using an allocator, they construct a <code>T</code> while passing along an allocator when possible</li>
  <li>Including additional rationale about the omission of allocating functions</li>
  <li>Added editorial alternatives</li>
  <li>Added implementation and deployment experience</li>
</ul>
<h3> R3 </h3>
<ul>
  <li>Rebased to N4861</li>
  <li>Putting wording back (in the form of instructions to editor)</li>
  <li>Per-header feature test macro, similar to <code>constexpr</code> macros</li>
</ul>
<h3> R2 </h3>
<ul>
  <li>Rebased to N4842</li>
  <li>No longer including <code>istream_view</code></li>
</ul>
<h3> R1 </h3>
<ul>
  <li>Adding section summarizing what is getting added</li>
  <li>Adding all of [ranges] and most of [iterators]</li>
  <li>Adding <code>uses_allocator_construction_args</code></li>
  <li>Adding feature test macro</li>
  <li>Now discussing split overload sets</li>
  <li>Dropping wording for now</li>
</ul>
<h3> R0 </h3>
<ul>
  <li>Branching from <a href="https://wg21.link/P0829R4">P0829R4</a>.  This "omnibus" paper is still the direction I am aiming for.  However, it is too difficult to review.  It needs to change with almost every meeting.  Therefore, it is getting split up into smaller, more manageable chunks</li>
  <li>Limiting paper to the [utilities], [ranges], and [iterators] clauses</li>
</p>
</ul>
<h1>Introduction</h1>
<p>
This paper proposes adding many of the facilities in the [utilities], [ranges], and [iterators] clause to the freestanding subset of C++.  The paper will be adding only complete entities, and will not tackle partial classes.  For example, classes like <code>pair</code> and <code>tuple</code> are being added, but trickier classes like <code>optional</code>, <code>variant</code>, and <code>bitset</code> will come in another paper.
</p><p>
The <code>&lt;memory&gt;</code> header depends on facilities in <code>&lt;ranges&gt;</code> and <code>&lt;iterator&gt;</code>, so those headers (and clauses) are addressed as well.
</p><p>
This paper also updates the editorial techniques for declaring facilities as freestanding. This update will make it easier to mark headers as partially freestanding. This wording change will also make it easier to mark in-flight proposals as freestanding, without causing a major blocking point in the standardization process.
</p><p>
The paper also includes a drive-by fix to add <code>_Exit</code> to freestanding.
<code>quick_exit</code> is already part of C++20's freestanding library, and <code>quick_exit</code> is specified to call <code>_Exit</code> <a href="https://eel.is/c++draft/support.start.term#13.sentence-5">[support.start.term#13]</a>.
This has been a bug since C++11 (introduced with LWG1264 / UK-172).
</p><p>
Changes to the design of feature test macros are discussed in <a href="https://wg21.link/P2198">P2198</a>.  This paper maintains the status quo for feature test macros on freestanding.
</p>
<h1>Motivation and Design</h1>
<p>
Many existing facilities in the C++ standard library could be used without trouble in freestanding environments.  This series of papers will specify the maximal subset of the C++ standard library that does not require an OS or space overhead.
</p><p>
For a more in-depth rationale, see <a href="https://wg21.link/P0829">P0829</a>.
</p><p>
This paper adds blanket wording to make it easier to mark things freestanding, and it retrofits the existing freestanding facilities to use the new editorial approach.  It also includes a non-normative note to allow implementers to use existing no-exception builds of their libraries as an implementation-defined extensions, with a fair number of qualifications.  Here's that note, reproduced so that it can be discussed more effectively:
</p><p>
<div class='note'>[ <span class='textit'>Note</span><span class='textit'>:</span> Throwing a standard library provided exception is not observably different from <span class='texttt'>terminate()</span> if the implementation doesn't unwind the stack during exception handling (<a href="http://eel.is/c++draft/except.handle#9">[except.handle#9]</a>) and the user's program contains no catch blocks. -<i>end note</i>]</div>
</p><p>
<code>&lt;optional&gt;</code>, <code>&lt;variant&gt;</code>, and <code>&lt;bitset&gt;</code> are not discussed in this paper, as all have non-essential functions that can throw an exception.  <code>&lt;charconv&gt;</code> is also not discussed in this paper as it will require us to deal with the thorny issue of overload sets involving floating point and non-floating point types.  I plan on addressing all four of these headers in later papers, so that the topics in question can be discussed in relative isolation.
</p>
<h1>Splitting overload sets</h1>
<p>
Modifying an overload set needs to be treated with great care.  Ideally, libraries built in freestanding environments will have the same semantics (including selected overloads) when built in a hosted environment.  I doubt that goal is fully attainable, as sufficiently clever programmers will be able to detect the difference and modify behavior accordingly.
</p><p>
My approach will be to avoid splitting overload sets that could cause accidental freestanding / hosted differences.  (In future papers, I may need to lean on <code>= delete</code> techniques to avoid silent behavior changes, but this paper hasn't needed that approach.)
</p><p>
<code>swap</code> has <code>shared_ptr</code>, <code>weak_ptr</code>, and <code>unique_ptr</code> overloads, but this paper marks only the <code>unique_ptr</code> overload as freestanding.  <code>&lt;memory&gt;</code> has many algorithms with <code>ExecutionPolicy</code> overloads.  This paper does not mark the <code>ExectuionPolicy</code> overloads as freestanding.  I was unable to come up with any compelling "accidental" way to select one <code>swap</code> or algorithm overload in freestanding, but a different one in hosted.
</p><p>
Also note that the <code>swap</code> overload set visible to a given translation unit is already indeterminate.  A user may include <code>&lt;memory&gt;</code> which guarantees the smart pointer overloads, but an implementation could expose any (or none!) of the other <code>swap</code> overloads from other STL headers.
</p>
<h1>Memory allocation and allocators</h1>
<p>
<a href="https://wg21.link/P2013">P2013</a> makes the default allocating <code>::operator new</code>s optional in freestanding.  This would make <code>std::allocator::allocate</code> ill-formed on implementations without an <code>::operator new</code> definition.
</p><p>
This paper (and most of the freestanding papers) will attempt to avoid adding facilities to freestanding that throw exceptions.
</p><p>
The Cpp17Allocator requirements permit only one and a half ways of signaling failures.  The first way to signal a failure is by throwing an exception; this is the only way to signal a failure that is explicitly described in <a href="https://wg21.link/allocator.requirements">[allocator.requirements]</a>.  The "half" of a way to signal a failure from an allocator is to <code>terminate</code>.  This can happen if the implementation has exceeded its (potentially tiny) implementation limits.  Note that returning <code>nullptr</code> is not an option here, as making <code>nullptr</code> a standard permitted error handling strategy for <code>std::allocator::allocate</code> would be a massively breaking change.
</p><p>
Future papers will attempt to add <code>constexpr</code> facilities to freestanding, so long as they are evaluated at compile time only.  The intent is for these future papers to allow a compile-time <code>std::vector</code> and <code>std::allocator</code>, but without requiring a runtime <code>std::vector</code> or <code>std::allocator</code>.
</p><p>
This paper shouldn't make any of those efforts more difficult to address in a distinct paper.  WG21 should not wait for those problems to be solved before adding the facilities in this paper to freestanding.
</p>
<h1>Justification for omissions</h1>
<p>
The following functions and classes rely on dynamic memory allocation and exceptions:
</p>
<ul>
  <li><code>make_unique</code></li>
  <li><code>make_unique_for_overwrite</code></li>
  <li><code>shared_ptr</code></li>
  <li><code>weak_ptr</code></li>
  <li><code>function</code></li>
  <li><code>boyer_moore_searcher</code></li>
  <li><code>boyer_moore_horspool_searcher</code></li>
</ul>
<p>
The following classes rely on iostreams facilities.  iostreams facilities use dynamic memory allocations and rely on the operating system.
</p>
<ul>
  <li><code>istream_iterator</code></li>
  <li><code>ostream_iterator</code></li>
  <li><code>istreambuf_iterator</code></li>
  <li><code>ostreambuf_iterator</code></li>
  <li><code>basic_istream_view</code></li>
  <li><code>istream_view</code></li>
</ul>
<p>
The ExecutionPolicy overloads of algorithms are of minimal utility on systems that do not support C++ threads.
</p>
<h1>Feature test macros</h1>
<p>
Feature test macros are non-trivial for this new design space, and are now discussed in paper <a href="https://wg21.link/P2198">P2198</a>.  For now, the present paper maintains the status quo with regards to the contents of <code>&lt;version&gt;</code>.
</p>

<h1>Dependency on <code>optional</code>-like thing in ranges</h1>
<p>
<a href="https://eel.is/c++draft/range.semi.wrap">[range.semi.wrap]</a> describes an exposition-only type with behavior specified in terms of <code>std::optional</code>.  This exposition-only type is used to specify <code>single_view</code>, <code>filter_view</code>, <code>transform_view</code>, <code>take_while</code>, and <code>drop_while_view</code>.  <code>std::optional</code> is not added in this paper.
</p><p>
I claim that this is not a problem.  First, the type <code>std::optional</code> is not required to be used here.  Second, <a href="https://eel.is/c++draft/compliance#2">[compliance] paragraph 2</a> permits implementations to provide extra headers, and an implementation could provide <code>std::optional</code> if it so desired.  Third, I plan on getting <code>std::optional</code> added to freestanding in a future paper that tackles the issue of omitting potentially throwing members, like <code>optional::value</code>.
</p>

<h1>Implementation and field experience</h1>
<p>
NI has been using a modified form of STLPort in the Microsoft Windows, Linux, and Apple OSX kernel for more than 10 years.  That only covers C++03 facilities though.
</p><p>
Paul Bendixen has implemented <a href="https://wg21.link/P0829">P0829</a> in a <a href="https://gitlab.com/avr-libstdcxx">libstdc++ fork</a>.  P0829 is (almost) a superset of the facilities in this paper.  This implementation is <a href="https://bintray.com/paulbendixen/paulbendixen/p0829%3Apaulbendixen">available on Conan</a>.
</p><p>
I have run a 2018 era of libc++'s test suite against the Microsoft Visual Studio 15.8 (released Aug 14, 2018) STL implementation, run in the Microsoft Windows kernel.  Running in that environment allowed me to audit whether exceptions, RTTI, memory allocation, or floating point was used in appropriately.  This largely tested the C++14 parts of the STL.  The C++17 and C++20 parts were either missing implementations, or tests.
</p>

<h1>Editorial alternatives</h1>
<p>
This paper uses an opt-in editorial syntax like the following:
<pre class='codeblock'>
#define NULL <span class='textit'><span class='texttt'>see below</span></span> <span class='comment'>// <span class='textit'>freestanding</span></span>
</pre>
</p><p>
This gives normative meaning to a comment in the synopsis.
There is precedent for this, particularly for <code>// exposition only</code> comments.
</p><p>
An alternative used by the POSIX spec would be to use an extra-lingual annotation to mark entities as freestanding or not.  Here, I'll use an italicized <code>[FS]</code> to indicate freestanding membership.
<pre class='codeblock'>
<i>[FS]</i> #define NULL <span class='textit'><span class='texttt'>see below</span></span>
</pre>
</p><p>
The choices of square brackets and the "FS" tag are arbitrary .  Other separators or tags could be used instead.  This would be a substantially new editorial technique for the C++ standard.
</p><p>
We could continue with the current approach, and use prose to indicate freestanding membership, similar to what we do with <code>abort</code> and friends in <a href="https://wg21.link/compliance">[compliance]</a>.  This would be a substantial amount of specification work for some headers.  It also hides the choice of freestanding, such that future paper authors are even less likely to keep it in mind.
</p><p>
When picking an editorial alternative, we should keep in mind likely future needs.  <a href="https://wg21.link/P0829">P0829</a> makes use of <i><code>//freestanding, partial</code></i> and <i><code>//freestanding, omit</code></i> annotations.  <a href="https://wg21.link/P1641R3">P1641R3</a> makes use of <i><code>//freestanding only</code></i> annotations.  I can also see uses for a <i><code>//freestanding delete</code></i> annotation, for maintaining overload sets while removing functionality.  These could be represented in the POSIX-like annotation as follows: <i><code>[FS partial]</code></i>, <i><code>[FS omit]</code></i>, <i><code>[FS only]</code></i>, and <i><code>[FS delete]</code></i>.
</p>

<h1>Status Quo</h1>
<p>
Please see <a href="https://wg21.link/compliance">[compliance]</a> to see what is freestanding in C++20.  Note that <code>NULL</code> and <code>size_t</code> are declared in both <code>&lt;cstdlib&gt;</code> and <code>&lt;cstddef&gt;</code>.  The wording in <a href="https://wg21.link/compliance">[compliance]</a> does not make it clear that <code>&lt;cstdlib&gt;</code> should continue to provide those declarations in a freestanding implementation.
</p>

<h1>Wording</h1>
<p>
The following wording is relative to N4868.
</p>

<h2>Change in <a href="https://wg21.link/conventions">[conventions]</a></h2>
Add a new subclause [freestanding.membership], under [conventions] and after [objects.within.classes]:
<blockquote class="stdins">
<h4 ><a class='secnum' style='min-width:118pt'>?.?.?.?</a> Freestanding membership <a class='abbr_ref'>[freestanding.membership]</a></h4>
<div class='para'>
    <div class='marginalizedparent'><a class='marginalized'>1</a></div>
    <div class='sentence'>Unless otherwise specified, the requirements on declarations and macro definitions in freestanding implementations shall be the same as the corresponding requirements in a hosted implementation.</div>
    <div class='note'>[ <span class='textit'>Note</span><span class='textit'>:</span> Throwing a standard library provided exception is not observably different from <span class='texttt'>terminate()</span> if the implementation doesn't unwind the stack during exception handling ([except.handle#9]) and the user's program contains no catch blocks. -<i>end note</i>]</div>
    <div class='sentence'>In the associated header synopsis for such declarations and macro definitions, the items are followed with a comment that includes <span class='textit'>freestanding</span>.</div>
	<div class='example'>[  <span class='textit'>Example:</span>
<pre class='codeblock'>
#define NULL <span class='textit'><span class='texttt'>see below</span></span> <span class='comment'>// <span class='textit'>freestanding</span></span>
</pre>
	-<i>end example</i>]</div>
</div>
<div class='para'>
    <div class='marginalizedparent'><a class='marginalized'>2</a></div>
    <div class='sentence'>A header all of whose declarations and macro definitions would be commented as specified above shall instead have a single such comment at the beginning of its synopsis.</div>
	<div class='example'>[  <span class='textit'>Example:</span>
<pre class='codeblock'>
<span class='comment'>// <span class='textit'>freestanding</span></span>
namespace std {
</pre>
	-<i>end example</i>]</div>
</div>
<div class='para'>
    <div class='marginalizedparent'><a class='marginalized'>3</a></div>
    <div class='sentence'>A <i>freestanding class template</i> is a class template that is implemented (partially or fully) in freestanding implementations.</div>
    <div class='sentence'>Deduction guides for freestanding class templates shall be implemented in freestanding implementations.</div>
    <div class='marginalizedparent'><a class='marginalized'>4</a></div>
    <div class='sentence'>A <i>freestanding declaration</i> is a non-namespace declaration that is implemented (partially or fully) in a freestanding implementation.</div>
    <div class='sentence'>The containing namespace of each freestanding declaration shall be provided in a freestanding implementation.</div>
</div>
</blockquote>
Wording involving comment placement is inspired by <a href="https://wg21.link/expos.only.func#1">[expos.only.func]#1</a>.  The "shalls" are all requirements on the implementation, and are similar to <a href="https://wg21.link/global.functions#3">[global.functions]#3</a>.


<h2>Changes in <a href="https://wg21.link/compliance">[compliance]</a></h2>
Add new rows to <a href="https://wg21.link/compliance#tab:headers.cpp.fs">Table 24</a>:</p>
<table style="border: 1px solid black">
<caption>Table 24: C++ headers for freestanding implementations [tab:headers.cpp.fs]</caption>
<thead>
<tr style="border: 1px solid black">
<th colspan="2" style="text-align: center">Subclause</th><th style="text-align: center">Header(s)</th>
</tr>
</thead>
<tbody>
<tr style="border: 1px solid black">
<td style="padding: 0ex 1ex 0ex 1ex">[&hellip;]</td>
<td style="padding: 0ex 1ex 0ex 1ex">[&hellip;]</td>
<td style="padding: 0ex 1ex 0ex 1ex">[&hellip;]</td>
</tr>
<tr style="border: 1px solid black">
<td style="padding: 0ex 1ex 0ex 1ex"><ins>?.? <a href="https://wg21.link/utility">[utility]</a></ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins>Utility components</ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins><tt>&lt;utility&gt;</tt></ins></td>
</tr>
<tr style="border: 1px solid black">
<td style="padding: 0ex 1ex 0ex 1ex"><ins>?.? <a href="https://wg21.link/tuple">[tuple]</a></ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins>Tuples</ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins><tt>&lt;tuple&gt;</tt></ins></td>
</tr>
<tr style="border: 1px solid black">
<td style="padding: 0ex 1ex 0ex 1ex"><ins>?.? <a href="https://wg21.link/memory">[memory]</a></ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins>Memory</ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins><tt>&lt;memory&gt;</tt></ins></td>
</tr>
<tr style="border: 1px solid black">
<td style="padding: 0ex 1ex 0ex 1ex"><ins>?.? <a href="https://wg21.link/function.objects">[function.objects]</a></ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins>Function objects</ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins><tt>&lt;functional&gt;</tt></ins></td>
</tr>
<tr style="border: 1px solid black">
<td style="padding: 0ex 1ex 0ex 1ex"><ins>?.? <a href="https://wg21.link/ratio">[ratio]</a></ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins>Compile-time rational arithmetic</ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins><tt>&lt;ratio&gt;</tt></ins></td>
</tr>
<tr style="border: 1px solid black">
<td style="padding: 0ex 1ex 0ex 1ex"><ins>?.? <a href="https://wg21.link/iterators">[iterators]</a></ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins>Iterators library</ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins><tt>&lt;iterator&gt;</tt></ins></td>
</tr>
<tr style="border: 1px solid black">
<td style="padding: 0ex 1ex 0ex 1ex"><ins>?.? <a href="https://wg21.link/ranges">[ranges]</a></ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins>Ranges library</ins></td>
<td style="padding: 0ex 1ex 0ex 1ex"><ins><tt>&lt;ranges&gt;</tt></ins></td>
</tr>
<tr style="border: 1px solid black">
<td style="padding: 0ex 1ex 0ex 1ex">[&hellip;]</td>
<td style="padding: 0ex 1ex 0ex 1ex">[&hellip;]</td>
<td style="padding: 0ex 1ex 0ex 1ex">[&hellip;]</td>
</tr>
</tbody>
</table>

Change in <a href="https://wg21.link/compliance#3">[compliance] paragraph 3</a>:
<blockquote class="std">
<div class='para'>
<del>
    <div class='sentence'>The supplied version of the header
    <span class='texttt'><span class='anglebracket'>&lt;</span>cstdlib<span class='anglebracket'>&gt;</span></span>
    shall declare at least the functions
    <span class='texttt'>abort</span>,
    <span class='texttt'>atexit</span>,
    <span class='texttt'>at_&shy;quick_&shy;exit</span>,
    <span class='texttt'>exit</span>,
    and
    <span class='texttt'>quick_&shy;exit</span> ([support.start.term]).</div>

    <div class='sentence'>The supplied version of the header <span class='texttt'><span class='anglebracket'>&lt;</span>atomic<span class='anglebracket'>&gt;</span></span>
    shall meet the same requirements as for a hosted implementation
    except that support for
    always lock-free integral atomic types ([atomics.lockfree])
    is implementation-defined, and
    whether or not the type aliases <span class='texttt'>atomic_&shy;signed_&shy;lock_&shy;free</span> and
    <span class='texttt'>atomic_&shy;unsigned_&shy;lock_&shy;free</span> are defined ([atomics.alias])
    is implementation-defined.</div>
    <div class='sentence'>The other headers listed in this table
    shall meet the same requirements as for a hosted implementation.</div>
</del>

<ins>
    <div class='sentence'>The headers listed in Table 24 shall meet the requirements for a freestanding implementation, as specified in the respective header synopsis.</div>
</ins>
</div>
</blockquote>

<h2>Full headers</h2>
Instructions to the editor:<br>
Please insert a <span class="comment">// <span class="textit">freestanding</span></span> comment at the beginning of the following synopses.  These headers are entirely freestanding.
<ul>
<li><a href="https://wg21.link/cstddef.syn">[cstddef.syn]</a></li>
<li><a href="https://wg21.link/limits.syn">[version.syn]</a></li>
<li><a href="https://wg21.link/limits.syn">[limits.syn]</a></li>
<li><a href="https://wg21.link/climits.syn">[climits.syn]</a></li>
<li><a href="https://wg21.link/cfloat.syn">[cfloat.syn]</a></li>
<li><a href="https://wg21.link/cstdint.syn">[cstdint.syn]</a></li>
<li><a href="https://wg21.link/new.syn">[new.syn]</a></li>
<li><a href="https://wg21.link/typeinfo.syn">[typeinfo.syn]</a></li>
<li><a href="https://wg21.link/source.location.syn">[source.location.syn]</a></li>
<li><a href="https://wg21.link/exception.syn">[exception.syn]</a></li>
<li><a href="https://wg21.link/initializer.list.syn">[initializer.list.syn]</a></li>
<li><a href="https://wg21.link/compare.syn">[compare.syn]</a></li>
<li><a href="https://wg21.link/coroutine.syn">[coroutine.syn]</a></li>
<li><a href="https://wg21.link/cstdarg.syn">[cstdarg.syn]</a></li>
<li><a href="https://wg21.link/concepts.syn">[concepts.syn]</a></li>
<li><a href="https://wg21.link/utility.syn">[utility.syn]</a></li>
<li><a href="https://wg21.link/tuple.syn">[tuple.syn]</a></li>
<li><a href="https://wg21.link/meta.type.synop">[meta.type.synop]</a></li>
<li><a href="https://wg21.link/ratio.syn">[ratio.syn]</a></li>
<li><a href="https://wg21.link/bit.syn">[bit.syn]</a></li>
</ul>

<h2>Change in <a href="https://wg21.link/cstdlib.syn">[cstdlib.syn]</a></h2>
Instructions to the editor:<br>
Please append a <span class="comment">// <span class="textit">freestanding</span></span> comment to the following entities:
<ul>
  <li><code>size_t</code></li>
  <li><code>NULL</code></li>
  <li><code>abort</code></li>
  <li>all overloads of <code>atexit</code></li>
  <li>all overloads of <code>at_quick_exit</code></li>
  <li><code>exit</code></li>
  <li><code>_Exit</code></li>
  <li><code>quick_exit</code></li>
</ul>

<h2>Change in <a href="https://wg21.link/memory.syn">[memory.syn]</a></h2>
Instructions to the editor:<br>
Please append a <span class="comment">// <span class="textit">freestanding</span></span> comment to the following entities:
<ul>
  <li><code>pointer_traits</code></li>
  <li><code>to_address</code></li>
  <li><code>align</code></li>
  <li><code>assume_aligned</code></li>
  <li><code>allocator_arg_t</code></li>
  <li><code>allocator_arg</code></li>
  <li><code>uses_allocator</code></li>
  <li><code>uses_allocator_v</code></li>
  <li><code>uses_allocator_construction_args</code></li>
  <li><code>make_obj_using_allocator</code></li>
  <li><code>uninitialized_construct_using_allocator</code></li>
  <li><code>allocator_traits</code></li>
  <li><code>addressof</code></li>
  <li><code>default_delete</code></li>
  <li><code>unique_ptr</code></li>
  <li><code>unique_ptr</code> overload of <code>swap</code></li>
  <li>relational operators (including three-way / spaceship) involving <code>unique_ptr</code></li>
  <li><code>hash</code></li>
  <li><code>unique_ptr</code> specialization of <code>hash</code></li>
  <li><code>atomic</code></li>
</ul>

Please append a <span class="comment">// <span class="textit">freestanding</span></span> comment to all overloads of the following function templates, except for the ExecutionPolicy overloads.
This includes the function templates in the <code>ranges</code> namespace.
<ul>
  <li><code>uninitialized_default_construct</code></li>
  <li><code>uninitialized_default_construct_n</code></li>
  <li><code>uninitialized_value_construct</code></li>
  <li><code>uninitialized_value_construct_n</code></li>
  <li><code>uninitialized_copy_result</code></li>
  <li><code>uninitialized_copy</code></li>
  <li><code>uninitialized_copy_n_result</code></li>
  <li><code>uninitialized_copy_n</code></li>
  <li><code>uninitialized_move_result</code></li>
  <li><code>uninitialized_move</code></li>
  <li><code>uninitialized_move_n_result</code></li>
  <li><code>uninitialized_move_n</code></li>
  <li><code>uninitialized_fill</code></li>
  <li><code>uninitialized_fill_n</code></li>
  <li><code>construct_at</code></li>
  <li><code>destroy_at</code></li>
  <li><code>destroy</code></li>
  <li><code>destroy_n</code></li>
</ul>

Note: the following portions of <code>&lt;memory&gt;</code> are <b>omitted</b>.  No change to the working draft should be made for these entities:
<ul>
  <li>[util.dynamic.safety], pointer safety</li>
  <li><code>allocator</code> and associated comparisons</li>
  <li><code>ExecutionPolicy</code> overloads in [specialized.algorithms]</li>
  <li><code>make_unique</code></li>
  <li><code>make_unique_for_overwrite</code></li>
  <li>All <code>operator&lt;&lt;</code> overloads</li>
  <li><code>bad_weak_ptr</code></li>
  <li><code>shared_ptr</code></li>
  <li><code>make_shared</code></li>
  <li><code>allocate_shared</code></li>
  <li><code>make_shared_for_overwrite</code></li>
  <li><code>allocate_shared_for_overwrite</code></li>
  <li>relational operators (including three-way / spaceship) involving <code>shared_ptr</code></li>
  <li><code>shared_ptr</code> overload of <code>swap</code></li>
  <li><code>static_pointer_cast</code></li>
  <li><code>dynamic_pointer_cast</code></li>
  <li><code>const_pointer_cast</code></li>
  <li><code>reinterpret_pointer_cast</code></li>
  <li><code>get_deleter</code></li>
  <li><code>weak_ptr</code></li>
  <li><code>weak_ptr</code> overload of <code>swap</code></li>
  <li><code>owner_less</code></li>
  <li><code>enable_shared_from_this</code></li>
  <li><code>shared_ptr</code> specialization of <code>hash</code></li>
  <li><code>shared_ptr</code> specialization of <code>atomic</code></li>
  <li><code>weak_ptr</code> specialization of <code>atomic</code></li>
</ul>

<h2>Change in <a href="https://wg21.link/functional.syn">[functional.syn]</a></h2>
Instructions to the editor:<br>
Please append a <span class="comment">// <span class="textit">freestanding</span></span> comment to every entity in <code>&lt;functional&gt;</code> <b>except</b> for the following entities:
<ul>
  <li><code>bad_function_call</code></li>
  <li><code>function</code></li>
  <li><code>function</code> overloads of <code>swap</code></li>
  <li><code>function</code> overloads of <code>operator==</code></li>
  <li><code>boyer_moore_searcher</code></li>
  <li><code>boyer_moore_horspool_searcher</code></li>
</ul>

<h2>Change in <a href="https://wg21.link/iterator.synopsis">[iterator.synopsis]</a></h2>
Instructions to the editor:<br>
Please append a <span class="comment">// <span class="textit">freestanding</span></span> comment to every entity in <code>&lt;iterator&gt;</code> <b>except</b> for the following entities:
<ul>
  <li><code>istream_iterator</code> and associated comparison operators</li>
  <li><code>ostream_iterator</code></li>
  <li><code>istreambuf_iterator</code> and associated comparison operators</li>
  <li><code>ostreambuf_iterator</code></li>
</ul>

<h2>Change in <a href="https://wg21.link/ranges.syn">[ranges.syn]</a></h2>
Instructions to the editor:<br>
Please append a <span class="comment">// <span class="textit">freestanding</span></span> comment to every entity in <code>&lt;ranges&gt;</code> <b>except</b> for the following entities:
<ul>
  <li><code>basic_istream_view</code></li>
  <li><code>istream_view</code></li>
</ul>

<h2>Change in <a href="https://wg21.link/atomics.lockfree">[atomics.lockfree]</a>, paragraph 2</h2>
<blockquote class="std">
<div class='para'>
<div class='sentence'><ins>On hosted implementations ([compliance]), a</ins><del>A</del>t least one signed integral specialization of the <span class='texttt'>atomic</span> template,
along with the specialization
for the corresponding unsigned type ([basic.fundamental]),
is always lock-free.</div>
<del><div class='note'>[&nbsp;<span class='textit'>Note</span><div class='noteBody'><span class='textit'>:</span> <div class='sentence'>This requirement is optional in freestanding implementations ([compliance]).</div> —&nbsp;<i>end note</i></div>&nbsp;]</div></del> </div>
</blockquote>

<h1>Acknowledgements</h1>
<p>
Thanks to Brandon Streiff, Joshua Cannon, Phil Hindman, and Irwan Djajadi for reviewing P0829.
</p><p>
Thanks to Odin Holmes for providing feedback and helping publicize P0829.
</p><p>
Thanks to Paul Bendixen for providing feedback while prototyping P0829.
</p><p>
Thanks to Walter Brown for providing wording feedback.
</p><p>
Similar work was done in the C++11 timeframe by Lawrence Crowl and Alberto Ganesh Barbati in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3256.html">N3256</a>.
</p>
</body>
</html>