<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
  <meta charset="utf-8" />
  <meta name="generator" content="mpark/wg21" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
  <meta name="dcterms.date" content="2025-01-13" />
  <title>The Plethora of Problems With Profiles</title>
  <style>
      code{white-space: pre-wrap;}
      span.smallcaps{font-variant: small-caps;}
      span.underline{text-decoration: underline;}
      div.column{display: inline-block; vertical-align: top; width: 50%;}
      div.csl-block{margin-left: 1.5em;}
      ul.task-list{list-style: none;}
      pre > code.sourceCode { white-space: pre; position: relative; }
      pre > code.sourceCode > span { display: inline-block; line-height: 1.25; }
      pre > code.sourceCode > span:empty { height: 1.2em; }
      .sourceCode { overflow: visible; }
      code.sourceCode > span { color: inherit; text-decoration: inherit; }
      div.sourceCode { margin: 1em 0; }
      pre.sourceCode { margin: 0; }
      @media screen {
      div.sourceCode { overflow: auto; }
      }
      @media print {
      pre > code.sourceCode { white-space: pre-wrap; }
      pre > code.sourceCode > span { text-indent: -5em; padding-left: 5em; }
      }
      pre.numberSource code
        { counter-reset: source-line 0; }
      pre.numberSource code > span
        { position: relative; left: -4em; counter-increment: source-line; }
      pre.numberSource code > span > a:first-child::before
        { content: counter(source-line);
          position: relative; left: -1em; text-align: right; vertical-align: baseline;
          border: none; display: inline-block;
          -webkit-touch-callout: none; -webkit-user-select: none;
          -khtml-user-select: none; -moz-user-select: none;
          -ms-user-select: none; user-select: none;
          padding: 0 4px; width: 4em;
          color: #aaaaaa;
        }
      pre.numberSource { margin-left: 3em; border-left: 1px solid #aaaaaa;  padding-left: 4px; }
      div.sourceCode
        {  background-color: #f6f8fa; }
      @media screen {
      pre > code.sourceCode > span > a:first-child::before { text-decoration: underline; }
      }
      code span { } /* Normal */
      code span.al { color: #ff0000; } /* Alert */
      code span.an { } /* Annotation */
      code span.at { } /* Attribute */
      code span.bn { color: #9f6807; } /* BaseN */
      code span.bu { color: #9f6807; } /* BuiltIn */
      code span.cf { color: #00607c; } /* ControlFlow */
      code span.ch { color: #9f6807; } /* Char */
      code span.cn { } /* Constant */
      code span.co { color: #008000; font-style: italic; } /* Comment */
      code span.cv { color: #008000; font-style: italic; } /* CommentVar */
      code span.do { color: #008000; } /* Documentation */
      code span.dt { color: #00607c; } /* DataType */
      code span.dv { color: #9f6807; } /* DecVal */
      code span.er { color: #ff0000; font-weight: bold; } /* Error */
      code span.ex { } /* Extension */
      code span.fl { color: #9f6807; } /* Float */
      code span.fu { } /* Function */
      code span.im { } /* Import */
      code span.in { color: #008000; } /* Information */
      code span.kw { color: #00607c; } /* Keyword */
      code span.op { color: #af1915; } /* Operator */
      code span.ot { } /* Other */
      code span.pp { color: #6f4e37; } /* Preprocessor */
      code span.re { } /* RegionMarker */
      code span.sc { color: #9f6807; } /* SpecialChar */
      code span.ss { color: #9f6807; } /* SpecialString */
      code span.st { color: #9f6807; } /* String */
      code span.va { } /* Variable */
      code span.vs { color: #9f6807; } /* VerbatimString */
      code span.wa { color: #008000; font-weight: bold; } /* Warning */
      code.diff {color: #898887}
      code.diff span.va {color: #006e28}
      code.diff span.st {color: #bf0303}
  </style>
  <style type="text/css">
body {
margin: 5em;
font-family: serif;

hyphens: auto;
line-height: 1.35;
text-align: justify;
}
@media screen and (max-width: 30em) {
body {
margin: 1.5em;
}
}
div.wrapper {
max-width: 60em;
margin: auto;
}
ul {
list-style-type: none;
padding-left: 2em;
margin-top: -0.2em;
margin-bottom: -0.2em;
}
a {
text-decoration: none;
color: #4183C4;
}
a.hidden_link {
text-decoration: none;
color: inherit;
}
li {
margin-top: 0.6em;
margin-bottom: 0.6em;
}
h1, h2, h3, h4 {
position: relative;
line-height: 1;
}
a.self-link {
position: absolute;
top: 0;
left: calc(-1 * (3.5rem - 26px));
width: calc(3.5rem - 26px);
height: 2em;
text-align: center;
border: none;
transition: opacity .2s;
opacity: .5;
font-family: sans-serif;
font-weight: normal;
font-size: 83%;
}
a.self-link:hover { opacity: 1; }
a.self-link::before { content: "§"; }
ul > li:before {
content: "\2014";
position: absolute;
margin-left: -1.5em;
}
: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; }
.header-section-number { 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;
}
a.itemDeclLink {
position: absolute;
font-size: 75%;
text-align: right;
width: 5em;
opacity: 0;
}
a.itemDeclLink:hover { opacity: 1; }
span.marginalizedparent {
position: relative;
left: -5em;
}
li span.marginalizedparent { left: -7em; }
li ul > li span.marginalizedparent { left: -9em; }
li ul > li ul > li span.marginalizedparent { left: -11em; }
li ul > li ul > li ul > li span.marginalizedparent { left: -13em; }
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: "⟵"; }

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;
}
.ncsimplebnf {
font-family: serif;
font-style: italic;
margin-top: 0.5em;
margin-bottom: 0.5em;
margin-left: 40pt;
background: inherit; 
}
span.textnormal {
font-style: normal;
font-family: serif;
white-space: normal;
display: inline-block;
}
span.rlap {
display: inline-block;
width: 0px;
}
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 { font-style: normal; }
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%;
}
.outputblock {
margin-left: 1.2em;
line-height: 127%;
}
div.itemdecl {
margin-top: 2ex;
}
code.itemdeclcode {
white-space: pre;
display: block;
}
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; 
}
td, th {
padding-left: 1em;
padding-right: 1em;
vertical-align: top;
}
td.empty {
padding: 0px;
padding-left: 1px;
}
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.even, tr.odd {
border-bottom: 1px solid black;
}
tr.capsep {
border-top: 3px solid black;
border-top-style: double;
}
tr.header {
border-bottom: 3px solid black;
border-bottom-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;
}
ol.enumeratea { list-style-type: none; background: inherit; }
ol.enumerate { list-style-type: none; background: inherit; }

code.sourceCode > span { display: inline; }
</style>
  <link href="data:image/x-icon;base64,AAABAAIAEBAAAAEAIABoBAAAJgAAACAgAAABACAAqBAAAI4EAAAoAAAAEAAAACAAAAABACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AIJEAACCRAAAgkQAAIJEAACCRAAAgkQAVoJEAN6CRADegkQAWIJEAACCRAAAgkQAAIJEAACCRAAA////AP///wCCRAAAgkQAAIJEAACCRAAsgkQAvoJEAP+CRAD/gkQA/4JEAP+CRADAgkQALoJEAACCRAAAgkQAAP///wD///8AgkQAAIJEABSCRACSgkQA/IJEAP99PQD/dzMA/3czAP99PQD/gkQA/4JEAPyCRACUgkQAFIJEAAD///8A////AHw+AFiBQwDqgkQA/4BBAP9/PxP/uZd6/9rJtf/bybX/upd7/39AFP+AQQD/gkQA/4FDAOqAQgBc////AP///wDKklv4jlEa/3o7AP+PWC//8+3o///////////////////////z7un/kFox/35AAP+GRwD/mVYA+v///wD///8A0Zpk+NmibP+0d0T/8evj///////+/fv/1sKz/9bCs//9/fr//////+/m2/+NRwL/nloA/5xYAPj///8A////ANKaZPjRmGH/5cKh////////////k149/3UwAP91MQD/lmQ//86rhv+USg3/m1YA/5hSAP+bVgD4////AP///wDSmmT4zpJY/+/bx///////8+TV/8mLT/+TVx//gkIA/5lVAP+VTAD/x6B//7aEVv/JpH7/s39J+P///wD///8A0ppk+M6SWP/u2sf///////Pj1f/Nj1T/2KFs/8mOUv+eWhD/lEsA/8aee/+0glT/x6F7/7J8Rvj///8A////ANKaZPjRmGH/48Cf///////+/v7/2qt//82PVP/OkFX/37KJ/86siv+USg7/mVQA/5hRAP+bVgD4////AP///wDSmmT40ppk/9CVXP/69O////////7+/v/x4M//8d/P//7+/f//////9u7n/6tnJf+XUgD/nFgA+P///wD///8A0ppk+NKaZP/RmWL/1qNy//r07///////////////////////+vXw/9akdP/Wnmn/y5FY/6JfFvj///8A////ANKaZFTSmmTo0ppk/9GYYv/Ql1//5cWm//Hg0P/x4ND/5cWm/9GXYP/RmGH/0ppk/9KaZOjVnmpY////AP///wDSmmQA0ppkEtKaZI7SmmT60ppk/9CWX//OkVb/zpFW/9CWX//SmmT/0ppk/NKaZJDSmmQS0ppkAP///wD///8A0ppkANKaZADSmmQA0ppkKtKaZLrSmmT/0ppk/9KaZP/SmmT/0ppkvNKaZCrSmmQA0ppkANKaZAD///8A////ANKaZADSmmQA0ppkANKaZADSmmQA0ppkUtKaZNzSmmTc0ppkVNKaZADSmmQA0ppkANKaZADSmmQA////AP5/AAD4HwAA4AcAAMADAACAAQAAgAEAAIABAACAAQAAgAEAAIABAACAAQAAgAEAAMADAADgBwAA+B8AAP5/AAAoAAAAIAAAAEAAAAABACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AP///wCCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAAyCRACMgkQA6oJEAOqCRACQgkQAEIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAA////AP///wD///8A////AIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRABigkQA5oJEAP+CRAD/gkQA/4JEAP+CRADqgkQAZoJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAAD///8A////AP///wD///8AgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAA4gkQAwoJEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAP+CRAD/gkQAxIJEADyCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAP///wD///8A////AP///wCCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAWgkQAmIJEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAJyCRAAYgkQAAIJEAACCRAAAgkQAAIJEAACCRAAA////AP///wD///8A////AIJEAACCRAAAgkQAAIJEAACCRAAAgkQAdIJEAPCCRAD/gkQA/4JEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAPSCRAB4gkQAAIJEAACCRAAAgkQAAIJEAAD///8A////AP///wD///8AgkQAAIJEAACCRAAAgkQASoJEANKCRAD/gkQA/4JEAP+CRAD/g0YA/39AAP9zLgD/bSQA/2shAP9rIQD/bSQA/3MuAP9/PwD/g0YA/4JEAP+CRAD/gkQA/4JEAP+CRADUgkQAToJEAACCRAAAgkQAAP///wD///8A////AP///wB+PwAAgkUAIoJEAKiCRAD/gkQA/4JEAP+CRAD/hEcA/4BBAP9sIwD/dTAA/5RfKv+viF7/vp56/76ee/+wiF7/lWAr/3YxAP9sIwD/f0AA/4RHAP+CRAD/gkQA/4JEAP+CRAD/gkQArIJEACaBQwAA////AP///wD///8A////AIBCAEBzNAD6f0EA/4NFAP+CRAD/gkQA/4VIAP92MwD/bSUA/6N1Tv/ezsL/////////////////////////////////38/D/6V3Uv9uJgD/dTEA/4VJAP+CRAD/gkQA/4JEAP+BQwD/fUAA/4FDAEj///8A////AP///wD///8AzJRd5qBlKf91NgD/dDUA/4JEAP+FSQD/cy4A/3YyAP/PuKP//////////////////////////////////////////////////////9K7qP94NQD/ciwA/4VJAP+CRAD/fkEA/35BAP+LSwD/mlYA6v///wD///8A////AP///wDdpnL/4qx3/8KJUv+PUhf/cTMA/3AsAP90LgD/4dK+/////////////////////////////////////////////////////////////////+TYxf91MAD/dTIA/31CAP+GRwD/llQA/6FcAP+gWwD8////AP///wD///8A////ANGZY/LSm2X/4ap3/92mcP+wdT3/byQA/8mwj////////////////////////////////////////////////////////////////////////////+LYxv9zLgP/jUoA/59bAP+hXAD/nFgA/5xYAPL///8A////AP///wD///8A0ppk8tKaZP/RmWL/1p9q/9ubXv/XqXj////////////////////////////7+fD/vZyG/6BxS/+gcUr/vJuE//r37f//////////////////////3MOr/5dQBf+dVQD/nVkA/5xYAP+cWAD/nFgA8v///wD///8A////AP///wDSmmTy0ppk/9KaZP/SmWP/yohJ//jo2P//////////////////////4NTG/4JDFf9lGAD/bSQA/20kAP9kGAD/fz8S/+Xb0f//////5NG9/6txN/+LOgD/m1QA/51aAP+cWAD/m1cA/5xYAP+cWADy////AP///wD///8A////ANKaZPLSmmT/0ppk/8+TWf/Unmv//v37//////////////////////+TWRr/VwsA/35AAP+ERgD/g0UA/4JGAP9lHgD/kFga/8KXX/+TRwD/jT4A/49CAP+VTQD/n10A/5xYAP+OQQD/lk4A/55cAPL///8A////AP///wD///8A0ppk8tKaZP/SmmT/y4tO/92yiP//////////////////////8NnE/8eCQP+rcTT/ez0A/3IyAP98PgD/gEMA/5FSAP+USwD/jj8A/5lUAP+JNwD/yqV2/694Mf+HNQD/jkAA/82rf/+laBj/jT4A8v///wD///8A////AP///wDSmmTy0ppk/9KaZP/LiUr/4byY///////////////////////gupX/0I5P/+Wuev/Lklz/l1sj/308AP+QSwD/ol0A/59aAP+aVQD/k0oA/8yoh///////+fXv/6pwO//Lp3v///////Pr4f+oay7y////AP///wD///8A////ANKaZPLSmmT/0ppk/8uJSv/hvJj//////////////////////+G7l//Jhkb/0ppk/96nc//fqXX/x4xO/6dkFP+QSQD/llEA/5xXAP+USgD/yaOA///////38uv/qG05/8ijdv//////8efb/6ZpLPL///8A////AP///wD///8A0ppk8tKaZP/SmmT/zIxO/9yxh///////////////////////7dbA/8iEQf/Sm2X/0Zlj/9ScZv/eqHf/2KJv/7yAQf+XTgD/iToA/5lSAP+JNgD/yKFv/611LP+HNQD/jT8A/8qmeP+kZRT/jT4A8v///wD///8A////AP///wDSmmTy0ppk/9KaZP/Pk1n/1J5q//78+//////////////////+/fv/1aFv/8iEQv/Tm2b/0ppl/9GZY//Wn2z/1pZc/9eldf/Bl2b/kUcA/4w9AP+OQAD/lUwA/59eAP+cWQD/jT8A/5ZOAP+eXADy////AP///wD///8A////ANKaZPLSmmT/0ppk/9KZY//KiEn/8d/P///////////////////////47+f/05tm/8iCP//KiEj/yohJ/8eCP//RmGH//vfy///////n1sP/rXQ7/4k4AP+TTAD/nVoA/5xYAP+cVwD/nFgA/5xYAPL///8A////AP///wD///8A0ppk8tKaZP/SmmT/0ptl/8uLTf/aq37////////////////////////////+/fz/6c2y/961jv/etY7/6Myx//78+v//////////////////////3MWv/5xXD/+ORAD/mFQA/51ZAP+cWAD/nFgA8v///wD///8A////AP///wDSmmTy0ppk/9KaZP/SmmT/0ppk/8mFRP/s1b//////////////////////////////////////////////////////////////////////////////+PD/0JFU/7NzMv+WUQD/kUsA/5tXAP+dWQDy////AP///wD///8A////ANKaZP/SmmT/0ppk/9KaZP/Sm2X/z5NZ/8yMT//z5NX/////////////////////////////////////////////////////////////////9Ofa/8yNUP/UmGH/36p5/8yTWv+qaSD/kksA/5ROAPz///8A////AP///wD///8A0ppk5NKaZP/SmmT/0ppk/9KaZP/TnGf/zY9T/82OUv/t1sD//////////////////////////////////////////////////////+7Yw//OkFX/zI5R/9OcZ//SmmP/26V0/9ymdf/BhUf/ol8R6P///wD///8A////AP///wDSmmQ80ppk9tKaZP/SmmT/0ppk/9KaZP/TnGj/zpFW/8qJSv/dson/8uHS//////////////////////////////////Lj0//etIv/y4lL/86QVf/TnGj/0ppk/9KaZP/RmWP/05xn/9ymdfjUnWdC////AP///wD///8A////ANKaZADSmmQc0ppkotKaZP/SmmT/0ppk/9KaZP/Tm2b/0Zli/8qJSf/NjlH/16Z3/+G8mP/myKr/5siq/+G8mP/Xp3f/zY5S/8qISf/RmGH/05tm/9KaZP/SmmT/0ppk/9KaZP/SmmSm0pljINWdaQD///8A////AP///wD///8A0ppkANKaZADSmmQA0ppkQtKaZMrSmmT/0ppk/9KaZP/SmmT/0ptl/9GYYf/Nj1P/y4lL/8qISP/KiEj/y4lK/82PU//RmGH/0ptl/9KaZP/SmmT/0ppk/9KaZP/SmmTO0ppkRtKaZADSmmQA0ppkAP///wD///8A////AP///wDSmmQA0ppkANKaZADSmmQA0ppkANKaZGzSmmTu0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmTw0ppkcNKaZADSmmQA0ppkANKaZADSmmQA////AP///wD///8A////ANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZBLSmmSQ0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppklNKaZBTSmmQA0ppkANKaZADSmmQA0ppkANKaZAD///8A////AP///wD///8A0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQy0ppkutKaZP/SmmT/0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppkvtKaZDbSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkAP///wD///8A////AP///wDSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkXNKaZODSmmT/0ppk/9KaZP/SmmT/0ppk5NKaZGDSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA////AP///wD///8A////ANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkBtKaZIbSmmTo0ppk6tKaZIrSmmQK0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZAD///8A////AP/8P///+B///+AH//+AAf//AAD//AAAP/AAAA/gAAAHwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA+AAAAfwAAAP/AAAP/8AAP//gAH//+AH///4H////D//" rel="icon" />
  
  <!--[if lt IE 9]>
    <script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
  <![endif]-->
</head>
<body>
<div class="wrapper">
<header id="title-block-header">
<h1 class="title" style="text-align:center">The Plethora of Problems
With Profiles</h1>
<table style="border:none;float:right">
  <tr>
    <td>Document #:</td>
    <td>
      P3586R0
      [<a href="https://wg21.link/P3586">Latest</a>]
      [<a href="https://wg21.link/P3586/status">Status</a>]
    </td>
  </tr>
  <tr>
    <td>Date:</td>
    <td>2025-01-13</td>
  </tr>
  <tr>
    <td style="vertical-align:top">Project:</td>
    <td>Programming Language C++</td>
  </tr>
  <tr>
    <td style="vertical-align:top">Audience:</td>
    <td>
      Evolution Working Group<br>
    </td>
  </tr>
  <tr>
    <td style="vertical-align:top">Reply-to:</td>
    <td>
      Corentin Jabot<br>&lt;<a href="mailto:corentin.jabot@gmail.com" class="email">corentin.jabot@gmail.com</a>&gt;<br>
    </td>
  </tr>
</table>
</header>
<div style="clear:both">
<h1 data-number="1" id="introduction"><span class="header-section-number">1</span> Introduction<a href="#introduction" class="self-link"></a></h1>
<p>Profiles (<span class="citation" data-cites="P3081R1"><a href="https://wg21.link/P3081" role="doc-biblioref">[P3081R1]</a></span>) aim to be a one-size-fits-all
solution to fix three different classes of problems.</p>
<ul>
<li>Some undefined behavior could be checked at runtime with (arguably)
some performance cost, and we would like tools to inject such
checks.</li>
<li>Some constructs are easy to misuse and could lead to unsafeties, and
we would like to detect these constructs and error on them (for example,
narrowing casts).</li>
<li>Some memory unsafeties could be semi-reliably detected through
compile time control flow analysis.</li>
</ul>
<p>However, these classes of problems should be considered
independently, as they are subject to widely different constraints and
design considerations.</p>
<h1 data-number="2" id="runtime-checks"><span class="header-section-number">2</span> Runtime checks<a href="#runtime-checks" class="self-link"></a></h1>
<p>As explained in <span class="citation" data-cites="P3543R0"><a href="https://wg21.link/p3543r0" role="doc-biblioref">[P3543R0]</a></span>, runtime checks, contracts,
and, to some extent, erroneous behavior all try to solve the same
problem, and a solution for runtime checks should, therefore, piggyback
on contracts, regardless of any perceived time pressure or deadline.</p>
<p>At the same time, <span class="citation" data-cites="P3081R1"><a href="https://wg21.link/P3081" role="doc-biblioref">[P3081R1]</a></span>
does not explore the proposal’s impact on existing widely deployed
solutions such as sanitizers.</p>
<p>It would make sense to come to a common understanding and a cohesive
set of features. The contract study group should be consulted on the
path forward and has been designing towards this end goal for quite a
while.</p>
<p>Therefore, the rest of the paper will focus on other aspects of the
profiles proposal, mostly the general design and how it deal with
dangerous syntatic constructs.</p>
<p>The lifetime analysis, as well as the recently proposed union
handling are not considered in this paper, as neither of these ideas
(which would benefit from deployment experience) are mature enough to be
fairly considered. However, Sean Baxter wrote an excellent, well
researched piece on the <a href="https://www.circle-lang.org/draft-profiles.html">short comings of
the lifetime profile</a>.</p>
<h1 data-number="3" id="ruminations-on-profile-opt-in-mechanisms"><span class="header-section-number">3</span> Ruminations on profile opt-in
mechanisms<a href="#ruminations-on-profile-opt-in-mechanisms" class="self-link"></a></h1>
<p>After many iterations, <span class="citation" data-cites="P3081R1"><a href="https://wg21.link/P3081" role="doc-biblioref">[P3081R1]</a></span>
is proposing that a profile can be opt-in on a per-TU basis through an
attribute (<code class="sourceCode cpp"><span class="op">[[</span><span class="at">profiles</span><span class="op">::</span><span class="at">enforce</span><span class="op">]]</span></code>).</p>
<p>The attribute syntax is problematic as it is currently accepted by
implementations, <a href="https://compiler-explorer.com/z/qaWhh49Ea">which will gladly
ignore it</a>. Note that this is not a philosophical question about the
ignorability of attributes. The fact of the matter is that older
toolchains will ignore the annotation and can’t be changed. Safety
features should not be ignorable; allowing them to be will lead to
vulnerabilities.</p>
<p>That mechanism interacts poorly with existing headers, which must be
assumed incompatible with any profiles. <span class="citation" data-cites="P3081R1"><a href="https://wg21.link/P3081" role="doc-biblioref">[P3081R1]</a></span> recognizes that and suggests -
That standard library headers are exempt from profile checking. - That
other headers may be exempt from profile checking in an
implementation-defined manner.</p>
<p>It is not clarified whether such exemptions apply to template
instantiations involving user-defined types and how these exemptions
would not promote vulnerabilities.</p>
<p>The standard library carve-out is yet another demonstration of how it
is problematic to try to apply the same tool to lexical constructs and
runtime behavior alike. Indeed, it might be reasonable not to error on
the presence of <code class="sourceCode cpp"><span class="kw">reinterpret_cast</span></code>
within the STL; however, would we really want to disable preconditions,
even when the preconditions would check user-provided values? This would
do nothing to improve safety.</p>
<p>At the time of writing, module support is also not mentioned. Does
the <code class="sourceCode cpp"><span class="op">[[</span><span class="at">profiles</span><span class="op">::</span><span class="at">enforce</span><span class="op">]]</span></code>
attribute apply to the GMF? Private partitions? How would profiles
impact ODR rules and importable headers?</p>
<p>And then, there is <code class="sourceCode cpp"><span class="op">[[</span><span class="at">profiles</span><span class="op">::</span><span class="at">apply</span><span class="op">]]</span></code>
- which produces warnings instead of errors. How does that work in any
non-toy software?</p>
<p>Surely, the control of warnings is the responsibility of the final
application and not its component libraries. Depending of one’s warning
and error policy, is the intent to edit a bunch of source files to turn
warnings into errors? Or use macros?</p>
<p>Again, that kind of behavior is best left to implementations. The
committee’s time is better spent identifying dangerous constructs and
offering replacements when possible rather than deciding if something
should be a warning, a fix-it, or how it interacts with
<code class="sourceCode cpp"><span class="op">-</span>Werror</code> and
the many diagnostic-controlling flags and features offered by
implementations.</p>
<h1 data-number="4" id="ruminations-on-profile-opt-out-mechanisms"><span class="header-section-number">4</span> Ruminations on profile opt-out
mechanisms<a href="#ruminations-on-profile-opt-out-mechanisms" class="self-link"></a></h1>
<p><code class="sourceCode cpp"><span class="op">[[</span><span class="at">profiles</span><span class="op">::</span><span class="at">suppress</span><span class="op">]]</span></code>
fails the <a href="https://eel.is/c++draft/dcl.attr#grammar-note-5">ignorability of
attributes</a> test. This is less problematic than for
<code class="sourceCode cpp">enforce</code> but it has not been
discussed.</p>
<p>It’s also very verbose and unergonomic for something that will have
to be used relatively frequently. (compared to Rust’s
<code class="sourceCode cpp">unsafe<span class="op">{}</span></code>
blocks, for example). It is very hard to qualify the usability of this
mechanism without usage experience.</p>
<p>It is also unclear that all rules should be suppress-able, when a
better alternative exists (for example,
<code class="sourceCode cpp">narrow_cast</code>).</p>
<h1 data-number="5" id="profiles-dont-have-a-good-backward-compatibility-story."><span class="header-section-number">5</span> Profiles don’t have a good
backward compatibility story.<a href="#profiles-dont-have-a-good-backward-compatibility-story." class="self-link"></a></h1>
<p><span class="citation" data-cites="P3081R1"><a href="https://wg21.link/P3081" role="doc-biblioref">[P3081R1]</a></span>
proposes categorizing profiles by kind of errors (type, numeric, memory,
etc.). Generally, users would expect cheap static checks, expansive
static analysis, and runtime checks to be controlled by separate flags.
There is a reasonable expectation that the runtime performance and the
compile time cost of a feature remains reasonably constant over
time.</p>
<p>As such that categorization (that mixes in a single profile different
kinds of checks), along with the fact that there is no description of
how profiles evolve and inter-operate in the long run, means that
profiles will not have a great backward-compatibility story.</p>
<h1 data-number="6" id="preventing-dangerous-constructs."><span class="header-section-number">6</span> Preventing dangerous
constructs.<a href="#preventing-dangerous-constructs." class="self-link"></a></h1>
<p><span class="citation" data-cites="P3081R1"><a href="https://wg21.link/P3081" role="doc-biblioref">[P3081R1]</a></span>
identifies some dangerous constructs and proposes to make them
conditionally ill-formed (or to force an implementation to warn on them,
more on that later).</p>
<ul>
<li><code class="sourceCode cpp"><span class="kw">reinterpret_cast</span></code></li>
<li><code class="sourceCode cpp"><span class="kw">const_cast</span></code></li>
<li>static downcasts</li>
<li>some C style casts</li>
<li>Pointer arithmetic</li>
<li>narrowing casts</li>
<li><code class="sourceCode cpp"><span class="kw">delete</span></code></li>
<li><code class="sourceCode cpp">va_arg</code></li>
<li>Array decay</li>
<li>…</li>
</ul>
<p>Not all of these constructs are safety issues for the same
reasons.</p>
<p>For example, static down casts and narrowing casts are dangerous
mostly because they are not clearly visible in the source. P3081R1
proposes a <code class="sourceCode cpp">narrow_cast</code> replacement
function (this is great). However, no replacement is proposed for static
downcasts. Yet, static downcasts are necessary to implement CRTP and
“homegrown” dynamic casting (LLVM’s
<code class="sourceCode cpp">dyn_cast</code>, Qt’s
<code class="sourceCode cpp"><span class="fu">qobject_cast</span></code>).
So, static downcast probably needs an explicit replacement - maybe one
with preconditions.</p>
<p><code class="sourceCode cpp"><span class="kw">reinterpret_cast</span></code>
is an obvious foot gun. However, its spelling makes that clear. Do we
want to encourage all usages of reinterpret_cast to be replaced by <code class="sourceCode cpp"><span class="op">[[</span><span class="at">profiles</span><span class="op">::</span><span class="at">suppress</span><span class="op">(</span><span class="at">type_safety</span><span class="op">)]]</span> <span class="kw">reinterpret_cast</span></code>?
What do we gain besides making users less attentive to the code they
write?</p>
<p><code class="sourceCode cpp"><span class="kw">const_cast</span><span class="op">&lt;</span><span class="kw">const</span> T<span class="op">&gt;</span></code>
is always acceptable, and whether it should be banned for safety reasons
is unclear. Should stripping away const be banned or should we research
ways to detect mutation of actually consts objects/subobjects? P3081R1
fails to be clear about the impact of this proposal.
<code class="sourceCode cpp"><span class="kw">const_cast</span></code>
is often in code bases that do not have const-correct-interfaces for
legacy reasons. Here, too, we should avoid forcing users to write <code class="sourceCode cpp"><span class="op">[[</span><span class="at">profiles</span><span class="op">::</span><span class="at">suppress</span><span class="op">(</span><span class="at">type_safety</span><span class="op">)]]</span> <span class="kw">const_cast</span><span class="op">&lt;&gt;</span></code>
everywhere. The safety implications of an invalid
<code class="sourceCode cpp"><span class="kw">const_cast</span></code>
have also not been explored. Is that UB exploitable in such a way that
it would be a safety concern?</p>
<p>Array decay is, unlike other features in that list, not a lexical
construct but a behavior of the language. Whether that behavior can be
changed needs much more work to determine impact and viability.</p>
<h2 data-number="6.1" id="should-delete-be-ill-formed"><span class="header-section-number">6.1</span> Should
<code class="sourceCode cpp"><span class="kw">delete</span></code> be
ill-formed?<a href="#should-delete-be-ill-formed" class="self-link"></a></h2>
<p>In its latest iteration <span class="citation" data-cites="P3081R1"><a href="https://wg21.link/P3081" role="doc-biblioref">[P3081R1]</a></span> proposes to make
<code class="sourceCode cpp"><span class="kw">delete</span></code> and
<code class="sourceCode cpp">free</code> rejected by the lifetime
<code class="sourceCode cpp">profile</code>. Presumably (the paper
offers no motivation), the intent is to discourage manual memory
management. However, allowing
<code class="sourceCode cpp"><span class="kw">new</span></code> and not
<code class="sourceCode cpp"><span class="kw">delete</span></code> could
encourage bad practices and resources leak (which, while not UB could be
a vulnerability) Rust considers allocations an unsafe operation, which
avoids that issue.</p>
<p>At the same time, rust also consider deferencing a raw pointer
unsafe, whereas just considering
<code class="sourceCode cpp"><span class="kw">delete</span></code>
unsafe would not materially help with use-after-free. The problem then
moves to <code class="sourceCode cpp">unique_ptr<span class="op">&lt;</span>T<span class="op">&gt;::</span>get<span class="op">()</span></code>.</p>
<h2 data-number="6.2" id="what-about-constant-evaluation"><span class="header-section-number">6.2</span> What about constant
evaluation?<a href="#what-about-constant-evaluation" class="self-link"></a></h2>
<p><span class="citation" data-cites="P3081R1"><a href="https://wg21.link/P3081" role="doc-biblioref">[P3081R1]</a></span>
whether dangerous constructs that are not potentially used, such as when
used only in constant or unevaluated context should be ill-formed
(despite not causing safety issues).</p>
<h1 data-number="7" id="p3081r1-is-detrimental-to-the-quality-of-implementations"><span class="header-section-number">7</span> P3081R1 is detrimental to the
quality of implementations<a href="#p3081r1-is-detrimental-to-the-quality-of-implementations" class="self-link"></a></h1>
<p><span class="citation" data-cites="P3081R1"><a href="https://wg21.link/P3081" role="doc-biblioref">[P3081R1]</a></span>
tries to offer novel recommendations for implementations</p>
<ul>
<li>to offer specific fix-its (replacements)</li>
<li>to offer specific warnings</li>
<li>to behave in a specific way in the presence of -Werror or
equivalent.</li>
</ul>
<p>Ultimately, this is not very useful to implementers or end-users and
is not a great use of committee time. Implementations have decades of
experience with what constitutes a suitable, useful, actionable warning.
At the same time, users have particular expectations regarding the
behavior of things like
<code class="sourceCode cpp"><span class="op">-</span>Werror</code> (as
well as diagnostic pragmas), etc.</p>
<p>Attempts to recommend different warning behaviors that would be
counterintuitive to user expectations or that would not otherwise
improve safety would just be ignored by implementations.
<code class="sourceCode cpp"><span class="op">-</span>Werror</code> will
continue to behave as
<code class="sourceCode cpp"><span class="op">-</span>Werror</code>
does.</p>
<p>Fix-it suggestions which are not universally applicable are also
unlikely to be implemented (for example, replacing
<code class="sourceCode cpp"><span class="kw">static_cast</span></code>
with
<code class="sourceCode cpp"><span class="kw">dynamic_cast</span></code>
could be, depending on the specifics of the project, not viable or a
terrible idea).</p>
<h1 data-number="8" id="p3081r1-mixes-safety-and-stylistic-concerns"><span class="header-section-number">8</span> P3081R1 mixes safety and
stylistic concerns<a href="#p3081r1-mixes-safety-and-stylistic-concerns" class="self-link"></a></h1>
<p><span class="citation" data-cites="P3081R1"><a href="https://wg21.link/P3081" role="doc-biblioref">[P3081R1]</a></span>
proposes, for example</p>
<ul>
<li>To mandate fix-it diagnostics for superfluous
<code class="sourceCode cpp"><span class="kw">dynamic_cast</span></code></li>
<li>To mandate fix-it replacement for <code class="sourceCode cpp"><span class="kw">static_cast</span><span class="op">&lt;</span>T<span class="op">&gt;(</span>T<span class="op">)</span></code>;</li>
<li>To mandate fix-it replacement for functional casts</li>
</ul>
<p>While these might be useful QoI behavior (often <a href="https://clang.llvm.org/extra/clang-tidy/checks/readability/redundant-casting.html">implemented
in static analyzers</a>), they do not expose security concerns and are
harmless or opinionated stylistic choices that are best left to users
implementers.</p>
<p>It is critical that any safety diagnostics only flags actually
dangerous constructs to avoid users silencing the warnings. Mixing
concerns would reduce any trust users may place in these
diagnostics.</p>
<h1 data-number="9" id="bound-checking-in-the-language-is-harmful-and-prevents-adoptability."><span class="header-section-number">9</span> Bound checking in the language is
harmful and prevents adoptability.<a href="#bound-checking-in-the-language-is-harmful-and-prevents-adoptability." class="self-link"></a></h1>
<p>One of the checks proposed by P3081R1 is to insert bound checks on
any <code class="sourceCode cpp"><span class="kw">operator</span><span class="op">[]</span></code>
of an arbitrary type that looks like a sequence container.</p>
<p>As explained in <span class="citation" data-cites="P3543R0"><a href="https://wg21.link/p3543r0" role="doc-biblioref">[P3543R0]</a></span>, many vector-looking
containers do not satisfy the semantic requirement of a vector-like
container such that their <code class="sourceCode cpp"><span class="kw">operator</span><span class="op">[]</span></code>,
or <code class="sourceCode cpp">size<span class="op">()</span></code>
member functions behave in interesting ways and trying to infer
semantics from lexical properties is a surefire way to break a lot of
existing applications.</p>
<p>Moreover, all standard implementations, Qt, folly, LLVM, abseil, and
others widely deploy frameworks all have checked preconditions on their
containers’ <code class="sourceCode cpp"><span class="kw">operator</span><span class="op">[]</span></code>,
which would lead to duplicate checks - and shows that this is mostly a
solved problem.</p>
<p>In fact, while writing this paper, <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112808">libstdc++
enabled bound checkings and other preconditions by default</a>.</p>
<p>Once <span class="citation" data-cites="P2900R0"><a href="https://wg21.link/p2900r0" role="doc-biblioref">[P2900R0]</a></span> is adopted, these will all
consolidate over time into precondition assertions, and the user story
will only get better.</p>
<h1 data-number="10" id="a-profile-by-any-other-name-would-still-be-a-subsetting-mechanism."><span class="header-section-number">10</span> A profile by any other name
would still be a subsetting mechanism.<a href="#a-profile-by-any-other-name-would-still-be-a-subsetting-mechanism." class="self-link"></a></h1>
<p>An enforced profile can make valid C++23 ill-formed. Therefore,
profiles are a subsetting mechanism. A dialect, if you will. And that’s
perfectly fine. It is not particularly useful to pretend otherwise or to
pretend that we will never want to break dangerous constructs over
time.</p>
<p>In fact, in the context of safety, it will be desirable or necessary
for dangerous constructs (implicit narrowing conversion, for example) to
stop being well-formed at some point.</p>
<p>However, it is interesting that profiles create as many dialects as
there are possible combinations of profiles (at least profiles that
impact language constructs), and while there is a lot of experiences
with C++ subsets and supersets (no exceptions/no RTTI/gnu
extensions/etc.), it seems desirable to avoid a combinatorial explosion
of restrictions and semantic changes as that would reduce the
interoperability of libraries and the overall health of the C++
ecosystem.</p>
<p>At the same time, in their current forms, profiles do not appear to
be a robust tool to subset the language. The interactions with modules,
template instantiations, default arguments, ODR, etc, are simply not
specified.</p>
<p>We clearly need a well-specified mechanism to offer a restricted set
of features in some translation units.</p>
<h2 data-number="10.1" id="the-age-of-epochs"><span class="header-section-number">10.1</span> The Age of Epochs<a href="#the-age-of-epochs" class="self-link"></a></h2>
<p>Epochs (<span class="citation" data-cites="P1881R1"><a href="https://wg21.link/p1881r1" role="doc-biblioref">[P1881R1]</a></span>) tried to define such a
solution and the paper already proposed safety-related restrictions.</p>
<p>Similarly, the visionary <span class="citation" data-cites="D0997R3"><a href="https://wg21.link/d0997r3" role="doc-biblioref">[D0997R3]</a></span> proposed to remove some
construcs from modules.</p>
<p>Modules, which constitute complete translation units, offer a natural
boundary for the subsetting of the language and resolve some of the
ODR-related concerns that arise by allowing different subsets and
language rules to exist at different points of the same translation
units.</p>
<p>Note that, should the standard define epochs, implementations could
offer flags to opt-in non-module TUs to a given epoch, which would help
with adoptability.</p>
<p>During the initial presentation of <a href="https://wg21.link/P1881R1">Epochs</a>, concerns were raised
regarding the interaction with templates.</p>
<p>However, if we limit epochs to making dangerous semantics ill-formed,
and we specify that the rules of an epoch equally apply to
specializations of declarations attached to a given epoch and their
default arguments/parameters, we can come up with a reasonable model.
Note that these questions apply equally to profiles and need to be
solved regardless.</p>
<p>Whether epochs should be allowed to have valid but different
semantics from one another is unclear. However, how much can be done
with epochs doesn’t need to be answered initially as long as we can make
them a reliable and predictable tool to make some constructs ill-formed,
including many of the dangerous lexical constructs identified by the
profile papers.</p>
<p>Compared to profiles, epochs would be better defined, non-ignorable,
fully specified, and avoid the concerns of having multiple conflicting
subsetting within the same TU.</p>
<p>At worst, C++ would have one epoch per cycle, which seems more
manageable than a profile proliferation.</p>
<h1 data-number="11" id="making-progress-on-safety"><span class="header-section-number">11</span> Making progress on safety<a href="#making-progress-on-safety" class="self-link"></a></h1>
<p>The various profiles-related paper identify somes sources of
unsafeties and attempt to solve them all with a single tool. As profiles
are an opt-it, ignorable feature, they do not meaningfully improve or
make the language safer or more usable over time, nor do they solve the
discoverability issues that current vendor tools might have. A lot of
the profiles aim to replicate what is already done by implementers.
Trying to standardize warnings or opinated fix-its is unlikely to
meaningfully improve the language in the long term. Profiles operate in
an area that implementations and tools (both open-source and commercial)
are actively exploring, researching, and innovating in.</p>
<p>That being said, it is evident that language safety should be an area
of focus, and there would be a lot of value in finding ways to evolve
the language by:</p>
<ul>
<li>Removing or deprecating dangerous constructs while providing more
explicit replacements</li>
<li>Consider an epoch-like mechanism if the removal of dangerous
constructs proves hard to adopt</li>
<li>Use contracts to detect some language UB at runtime as proposed in
<span class="citation" data-cites="P2900R0"><a href="https://wg21.link/p2900r0" role="doc-biblioref">[P2900R0]</a></span></li>
<li>Keep working with standard library implementations to enforce
preconditions</li>
<li>Keep working with implementations and tool providers on control flow
analysis tools until these tools are sufficiently mature to decide
whether any part should be standardized</li>
<li>Explore long-term language solutions for memory safety.</li>
<li>Explore whether the committee could help in the adoption of
CHERI/MTE/pointer authentication.</li>
<li>Explore ways to improve compatibility and interfaces with
memory-safe languages, which are becoming the tools of choice in some
industries.</li>
<li>Not closing doors prematurely. Many ideas are worth considering,
even if they are scary or ambitious.</li>
</ul>
<p>C++’s safety story should involve an array of standard changes and
vendor-provided solutions, applying the right tools to each problem</p>
<table>
<colgroup>
<col style="width: 20%" />
<col style="width: 20%" />
<col style="width: 20%" />
<col style="width: 20%" />
<col style="width: 20%" />
</colgroup>
<thead>
<tr class="header">
<th></th>
<th><div style="text-align:center">
<strong>Dangerous constructs</strong>
</div></th>
<th><div style="text-align:center">
<strong>Language UB</strong>
</div></th>
<th><div style="text-align:center">
<strong>Library UB</strong>
</div></th>
<th><div style="text-align:center">
<strong>Memory/Lifetime/Thread<br />Safeties</strong>
</div></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>WG21</td>
<td>Depreciation<br />Removal<br />Replacement<br />Epochs</td>
<td>Contracts<br />Erroneous Behavior<br />Safer alternatives</td>
<td>Contracts<br />Unsafe functions coloring?</td>
<td>Research towards Safe C++?<br />Non trivial relocation?</td>
</tr>
<tr class="even">
<td>Vendors</td>
<td>Warnings<br />Guidelines<br />Static analysis</td>
<td>Sanitizers</td>
<td></td>
<td>Sanitizers<br />Pointer Tagging<br />Static analysis</td>
</tr>
</tbody>
</table>
<h2 data-number="11.1" id="on-trains-and-missing-them"><span class="header-section-number">11.1</span> On trains and missing them<a href="#on-trains-and-missing-them" class="self-link"></a></h2>
<p>Safety is critical to the future of C++. However, we should not let a
sense of urgency get the better of us. There are two scenarios to
consider here:</p>
<ul>
<li>Either a given language-safety-related feature can be backported to
older C++ versions, so it will (implementers care about safety,
too!).</li>
<li>It is C++26 or C++29-specific and, for some reason, can’t be
backported as a conforming extension. In that case, given the low
adoption rate of C++26 at this time, pushing it to early C++29 would
have no impact.</li>
</ul>
<p>It is also worth noting that nothing in profiles in their current
form is normative enough that it couldn’t be pursued as a standalone
guideline outside of the standard and its release cycle. Concerns with
language safety far predate our renewed interest, and regulatory
pressure isn’t a very good reason to try to solve a very complex and
multi-faceted issue in a few weeks. There is going to be another
train.</p>
<h1 data-number="12" id="further-reads"><span class="header-section-number">12</span> Further reads<a href="#further-reads" class="self-link"></a></h1>
<ul>
<li><a href="https://chandlerc.blog/posts/2024/11/story-time-bounds-checking/">Story-time:
C++, bounds checking, performance, and compilers</a></li>
<li><a href="https://security.googleblog.com/2024/11/retrofitting-spatial-safety-to-hundreds.html">Retrofitting
spatial safety to hundreds of millions of lines of C++</a></li>
<li><a href="https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html">Eliminating
Memory Safety Vulnerabilities at the Source</a></li>
<li><a href="https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/">Towards
the next generation of XNU memory safety</a></li>
<li><a href="https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html">Compiler
Options Hardening Guide for C and C++</a></li>
<li><a href="https://airbus-seclab.github.io/c-compiler-security/">Getting the
maximum of your C compiler, for security</a></li>
<li><a href="https://clang.llvm.org/extra/clang-tidy/checks/list.html">Clang-Tidy
Checks</a></li>
<li><a href="https://developers.redhat.com/blog/2021/05/05/memory-error-checking-in-c-and-c-comparing-sanitizers-and-valgrind">Memory
error checking in C and C++: Comparing Sanitizers and Valgrind</a></li>
<li><a href="https://clang.llvm.org/docs/ControlFlowIntegrity.html">Control
Flow Integrity</a></li>
<li><a href="https://clang.llvm.org/docs/SafeBuffers.html">Safe
Buffers</a></li>
<li><a href="https://safecpp.org/draft.html">Safe C++</a></li>
<li><a href="https://www.youtube.com/watch?v=XNOPO3ogdfQ">Clang
IR</a></li>
<li><a href="https://arxiv.org/pdf/1802.09517">Memory Tagging and how it
improves C/C++ memory safety</a></li>
<li><a href="https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf">CHERI</a></li>
<li><a href="https://llvm.org/docs/PointerAuth.html">Pointer
Authentication</a></li>
<li><a href="https://doc.rust-lang.org/nomicon/">The
Rustonomicon</a></li>
<li><a href="https://github.com/rustfoundation/interop-initiative">C++/Rust
Interoperability Problem Statement</a></li>
<li><a href="https://arxiv.org/pdf/2003.03296">Memory-Safety Challenge
Considered Solved? An In-Depth Study with All Rust CVEs</a></li>
<li><a href="https://ferrocene.dev/en/">Ferocenne</a></li>
<li><a href="https://plv.mpi-sws.org/rustbelt/stacked-borrows/paper.pdf">Stacked
Borrows: An Aliasing Model for Rust</a></li>
<li><a href="https://www.cisa.gov/sites/default/files/2023-12/CSAC_TAC_Recommendations-Memory-Safety_Final_20231205_508.pdf">Report
to CISA - Technical Advisory Council, Memory Safety</a></li>
<li><a href="https://arxiv.org/pdf/2201.10599">The Unexplored Terrain of
Compiler Warnings</a></li>
</ul>
<h2 data-number="12.1" id="videos"><span class="header-section-number">12.1</span> Videos<a href="#videos" class="self-link"></a></h2>
<ul>
<li><a href="https://www.youtube.com/watch?v=gG4BJ23BFBE">The
existential threat against C++ and where to go from here</a></li>
<li><a href="https://www.youtube.com/watch?v=t7EJTO0-reg">Security in
C++ - Hardening Techniques From the Trenches</a></li>
<li><a href="https://www.youtube.com/watch?v=glkMbNLogZE">Embracing an
Adversarial Mindset for C++ Security</a></li>
<li><a href="https://www.youtube.com/watch?v=Gh79wcGJdTg">Safety and
Security: The Future of C++</a></li>
<li><a href="https://www.youtube.com/watch?v=PFdKFoQxRqM">Fixing C++
with Epochs</a></li>
<li><a href="https://www.youtube.com/watch?v=SEFaC0wkaVE">Mitigating
lifetime issues for C++20 coroutines</a></li>
</ul>
<h1 data-number="13" id="acknowledgments"><span class="header-section-number">13</span> Acknowledgments<a href="#acknowledgments" class="self-link"></a></h1>
<p>Thanks to David Ledger and Joshua Bern for reviewing drafts of this
paper. Thanks to Erich Keane, Aaron Ballman, and Shafik Yagmour for
insightful conversations and feedbacks.</p>
<h1 data-number="14" id="bibliography"><span class="header-section-number">14</span> References<a href="#bibliography" class="self-link"></a></h1>
<div id="refs" class="references csl-bib-body hanging-indent" data-entry-spacing="1" role="doc-bibliography">
<div id="ref-D0997R3" class="csl-entry" role="doc-biblioentry">
[D0997R3] Draft 3 P0997 <span>“Retire Pernicious Language Constructs in
Module Contexts.”</span> <a href="https://wg21.link/d0997r3"><div class="csl-block">https://wg21.link/d0997r3</div></a>
</div>
<div id="ref-P1881R1" class="csl-entry" role="doc-biblioentry">
[P1881R1] Vittorio Romeo. 2020-01-12. Epochs: a backward-compatible
language evolution mechanism. <a href="https://wg21.link/p1881r1"><div class="csl-block">https://wg21.link/p1881r1</div></a>
</div>
<div id="ref-P2900R0" class="csl-entry" role="doc-biblioentry">
[P2900R0] Joshua Berne, Timur Doumler, Andrzej Krzemieński. 2023-09-27.
Contracts for C++. <a href="https://wg21.link/p2900r0"><div class="csl-block">https://wg21.link/p2900r0</div></a>
</div>
<div id="ref-P3081R1" class="csl-entry" role="doc-biblioentry">
[P3081R1] Herb Sutter. Core safety Profiles: Specification,
adoptability, and impact. <div class="csl-block"><a href="https://wg21.link/P3081">wg21.link/P3081</a></div>
</div>
<div id="ref-P3543R0" class="csl-entry" role="doc-biblioentry">
[P3543R0] Mungo Gill, Corentin Jabot, John Lakos, Joshua Berne, Timur
Doumler. 2024-12-17. Response to Core Safety Profiles (P3081). <a href="https://wg21.link/p3543r0"><div class="csl-block">https://wg21.link/p3543r0</div></a>
</div>
</div>
</div>
</div>
</body>
</html>
