﻿<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta charset="utf-8" />
  <title>C++17 should refer to C11 instead of C99</title>
  <style type="text/css">
    .new {
      border-style: solid;
      border-width: thin;
    }

      p.new, .new > p {
        padding-left: 1em;
        padding-right: 1em;
      }

    del {
      background-color: #FCC;
    }

    ins {
      background-color: #CFC;
    }
  </style>
</head>
<body>
  <table border="1">
    <tr>
      <th>Doc. No.:</th>
      <td>P0063R3</td>
    </tr>
    <tr>
      <th>Date:</th>
      <td>2016-06-23</td>
    </tr>
    <tr>
      <th>Reply to:</th>
      <td>Clark Nelson</td>
      <td>Hans-J. Boehm</td>
    </tr>
    <tr>
      <th>Email:</th>
      <td>clark.nelson@intel.com</td>
      <td>hboehm@google.com</td>
    </tr>
    <tr>
      <th>Audience:</th>
      <td>Library Evolution</td>
    </tr>
  </table>
  <h1>C++17 should refer to C11 instead of C99</h1>
  <h1>Introduction</h1>
  <p>This document is a follow-on to
    <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0063r0.html">P0063R0</a>,
    from the pre-Kona mailing.
    It goes into the details of the &ldquo;easy part&rdquo;
    described therein.
    Much of its rationale is not repeated here.</p>
  <p class="new">It has also been revised
    as a result of LEWG review in Jacksonville.
    Changes from R1 are boxed.</p>
  <h2>Signal handler restrictions</h2>
  <p>18.10p10 effectively says that a signal handler
    must be written in the common subset of C and C++.
    But C++ and C11 both have thread-local storage.
    Referencing C11 instead of C99 might be taken to suggest
    that it would be OK for a signal handler to reference
    a thread-local object.</p>
  <p>It turns out that there is a technicality/loophole
    by which this can be dodged.
    Because the associated keyword is spelled differently
    in C and C++, technically thread-local storage
    is not actually in the common subset of the two languages &ndash;
    even though both languages support the feature.</p>
  <p>While this state would not provide
    a satisfying long-term resolution,
    it is considered adequate to separate
    the deep technical issues of signal handlers
    from the broader, more editorial issues
    of updating the normative reference.
    Hans has written <a href="#p0270">P0270</a>
    to address signal handlers.</p>
  <p>This document also doesn't go into interoperability
    of threads or atomics
    in a mixed C/C++ program.</p>
  <h2>Header coverage</h2>
  <p>C11 made the <code>&lt;complex.h&gt;</code> header optional.
    Currently in C++, the <code>&lt;ccomplex&gt;</code> header
    maps directly to the <code>&lt;complex&gt;</code> header.
    Simply deleting the requirement
    for a <code>&lt;ccomplex&gt;</code> header
    is simpler, and may be better, than making it optional.
    Of course an implementation would not need to change
    in order to conform to the new state of affairs,
    but programs that use <code>&lt;ccomplex&gt;</code>
    instead of <code>&lt;complex&gt;</code>
    would cease to be strictly conforming.</p>
  <p>C11 also added five new headers:</p>
  <dl>
    <dt><code>&lt;stdatomic.h&gt;</code></dt>
    <dt><code>&lt;threads.h&gt;</code></dt>
    <dd>These are also optional in C11,
      and since their functionality is already provided in C++ by other means,
      it's not clear that inventing optional wrappers for them
      would be worth the effort.</dd>
    <dt><code>&lt;stdalign.h&gt;</code></dt>
    <dt><code>&lt;uchar.h&gt;</code></dt>
    <dd>C++ already covers these two,
      having inherited one of them from the C Unicode TR
      (later incorporated into C11),
      and having effectively jumped the gun on the other one.</dd>
    <dt><code>&lt;stdnoreturn.h&gt;</code></dt>
    <dd>All this provides is a single prettifying macro:
      <pre>#define noreturn _Noreturn</pre>
      In C++, <code>[[noreturn]]</code>
      is probably already considered pretty enough.</dd>
  </dl>
  <p>So it's not clear that C++ needs to add anything
    for any of these new headers.</p>
  <p class="new">LEWG decided
    that <code>&lt;stdatomic.h&gt;</code>,
    <code>&lt;stdnoreturn.h&gt;</code>
    and <code>&lt;threads.h&gt;</code>
    should all be ignored &ndash;
    except that there should be a footnote pointing out
    that their omission is intentional.</p>
  <p class="new">It was also decided that the existing headers
    <code>&lt;ccomplex&gt;</code>
    and <code>&lt;ctgmath&gt;</code>
    should be deprecated.
    <code>&lt;ciso646&gt;</code>
    was called out as explicitly having no effect
    according to the standard,
    but apparently the real world is not so simple.
    <code>&lt;cstdalign&gt;</code>
    and 
    <code>&lt;cstdbool&gt;</code>
    were mentioned as also being pointless in C++,
    but were not the subject of any straw poll;
    I have taken the liberty of assuming
    that perhaps they should be deprecated as well.</p>
  <h2>Annex K &emsp; Bounds checking interfaces</h2>
  <p>C11 optionally added several dozen new functions
    to the standard library,
    as safer alternatives to existing standard C library functions.
    For example, <code>strcat_s</code> was added as an alternative to
    <code>strcat</code>.</p>
  <p>The declarations of these functions
    were added to existing headers;
    backward compatibility was provided
    by requiring that they be controlled by the setting of a macro:
    <code>__STDC_WANT_LIB_EXT1__</code>.
    A program can suppress them by defining the macro to zero,
    or request them by defining the macro to one.
    Whether they are declared if the macro is not defined
    by the program is implementation-defined.</p>
  <p>At a recent WG14 meeting,
    a proposal was considered
    (<a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm">N1967</a>)
    that these functions should be removed
    from a future revision of the standard.</p>
  <p class="new">LEWG decided that these functions
    should not be imported into the <code>std</code> namespace,
    but that it should be entirely implementation-defined
    whether they are declared in the global namespace.
    (Any implementation can document
    that it does the full &ldquo;macro dance&rdquo;
    described by the C standard.)</p>
  <h2>Working draft changes</h2>
  <h3>1.2 &emsp; Normative references</h3>
  <p>Change paragraph 1:</p>
  <blockquote>
    <p>...</p>
    <ul>
      <li>...</li>
      <li>ISO/IEC 9899:<del>1999</del><ins>2011</ins>,
	<em>Programming languages &mdash; C</em></li>
      <li>ISO/IEC 9899:<del>1999</del><ins>2011</ins>/Cor
	1:<del>2001</del><ins>2012</ins>(E),
	<em>Programming languages &mdash; C,
	  Technical Corrigendum 1</em></li>
      <li><del>ISO/IEC 9899:1999/Cor.2:2004(E),
	<em>Programming languages &mdash; C,
	  Technical Corrigendum 2</em></del></li>
      <li><del>ISO/IEC 9899:1999/Cor.3:2007(E),
	<em>Programming languages &mdash; C,
	  Technical Corrigendum 3</em></del></li>
      <li>...</li>
      <li><del>ISO/IEC TR 19769:2004,
	<em>Information technology &mdash; Programming languages,
	their environments and system software interfaces &mdash;
	Extensions for the programming language C
	to support new character data types</em></del></li>
    </ul>
  </blockquote>
  <p>Change paragraph 2:</p>
  <blockquote>
    <p>The library described in Clause 7
      of ISO/IEC 9899:<del>1999</del><ins>2011</ins>
      <del>and Clause 7 of ISO/IEC 9899:1999/Cor.1:2001
	and Clause 7 of ISO/IEC 9899:1999/Cor.2:2003</del>
      is hereinafter called
	the <dfn>C standard library</dfn>.<sup>1</sup></p>
  </blockquote>
  <p>Delete paragraph 3:</p>
  <blockquote>
    <p><del>The library described in ISO/IEC TR 19769:2004
      is hereinafter called the <dfn>C Unicode TR</dfn>.</del></p>
  </blockquote>
  <h3>17.5.1.5 &emsp; C Library</h3>
  <p>Change paragraph 1:</p>
  <blockquote>
    <p class="new">Paragraphs labeled &ldquo;See also:&rdquo;
      contain cross-references to the relevant portions
      of this International Standard
      and the ISO C standard<del>,
      which is incorporated into this International Standard
      by reference</del>.</p>
  </blockquote>
  <h3>17.5.2.1.4 &emsp; Character sequences</h3>
  <p>Delete footnote 167, associated with paragraph 1, bullet 1:</p>
  <blockquote class="new">
    <ul>
      <li>A <dfn>letter</dfn> is any of the 26 lowercase or 26 uppercase letters in the basic execution character set.<del><sup>167</sup></del></li>
    </ul>
    <p><del>167) Note that this definition differs
      from the definition in ISO C 7.1.1.</del></p>
  </blockquote>
  <p>Apparently there was a time
    when the definition of &ldquo;letter&rdquo;
    also included the underscore,
    but that is no longer the case.</p>
  <h3>17.6.1.2 &emsp; Headers</h3>
  <p>Add a footnote to paragraph 3:</p>
  <blockquote class="new">
    <p>The facilities of the C standard Library are provided in 26 additional headers, as shown in Table 15.<ins><sup><var>N</var>)</sup></ins></p>
    <p><ins><var>N</var>) It is intentional
      that there is no C++ header for any of
      these C headers: <code>&lt;stdatomic.h></code>,
      <code>&lt;stdnoreturn.h></code>, 
      <code>&lt;threads.h></code>.</ins></p>
  </blockquote>
  <p>Change paragraph 4:</p>
  <blockquote>
    <p>Except as noted in Clauses 18 through 30 and Annex D,
      the contents of each header <code>c</code><var>name</var>
      shall be the same as that of the corresponding header
      <var>name</var><code>.h</code>,
      as specified in the C standard library (1.2)
      <del>or the C Unicode TR, as appropriate,</del>
      as if by inclusion.
      In the C++ standard library, however,
      the declarations
      (except for names which are defined as macros in C)
      are within namespace scope (3.3.6)
      of the namespace <code>std</code>.
      It is unspecified whether these names
      (including any overloads added
      in Clauses 18 through 30 and Annex D)
      are first declared within the global namespace scope
      and are then injected into namespace <code>std</code>
      by explicit <var>using-declarations</var> (7.3.3).</p>
  </blockquote>
  <p>Add new paragraphs, and table, following paragraph 8:</p>
  <blockquote class="new">
    <p><ins>Annex K of the C standard
      describes a large number of functions,
      with associated types and macros,
      which &ldquo;promote safer, more secure programming&rdquo;
      than many of the traditional C library functions.
      The names of the functions
      have a suffix of <code>_s</code>;
      most of them provide the same service as the C library function
      with the unsuffixed name,
      but generally take an additional argument
      whose value is the size of the result array.
      If any C++ header is included,
      it is implementation-defined
      whether any of these names is declared
      in the global namespace.
      (None of them is declared
      in namespace <code>std</code>.)</ins></p>
    <p><ins>Table <var>N</var> lists the Annex K names
      that may be declared in some header.
      These names are also subject
      to the restrictions of [macro.names].</ins></p>
    <p><ins><strong>Table <var>N</var> &mdash;
      C standard Annex K names</strong></ins></p>
    <pre>abort_handler_s       asctime_s                 bsearch_s
constraint_handler_t  ctime_s                   errno_t
fopen_s               fprintf_s                 freopen_s
fscanf_s              fwprintf_s                fwscanf_s
getenv_s              gets_s                    gmtime_s
ignore_handler_s      L_tmpnam_s                localtime_s
mbsrtowcs_s           mbstowcs_s                memcpy_s
memmove_s             memset_s                  printf_s
qsort_s               RSIZE_MAX                 rsize_t
scanf_s               set_constraint_handler_s  snprintf_s
snwprintf_s           sprintf_s                 sscanf_s
strcat_s              strcpy_s                  strerror_s
strerrorlen_s         strlen_s                  strncat_s
strncpy_s             strtok_s                  swprintf_s
swscanf_s             tmpfile_s                 TMP_MAX_S
tmpnam_s              vfprintf_s                vfscanf_s
vfwprintf_s           vfwscanf_s                vprintf_s
vscanf_s              vsnprintf_s               vsnwprintf_s
vsprintf_s            vsscanf_s                 vswprintf_s
vswscanf_s            vwprintf_s                vwscanf_s
wcrtomb_s             wcscat_s                  wcscpy_s
wcsncat_s             wcsncpy_s                 wcsnlen_s
wcsrtombs_s           wcstok_s                  wcstombs_s
wctomb_s              wmemcpy_s                 wmemmove_s
wprintf_s             wscanf_s</pre>
  </blockquote>
  <h3>18.2 &emsp; Types</h3>
  <p>Change reference to C standard for paragraph 9:</p>
  <blockquote>
    <p>See also: ... ISO C <del>7.1.6</del> <ins>7.19</ins>.</p>
  </blockquote>
  <h3>18.3.3 &emsp; C library</h3>
  <p>Change table 32:</p>
  <blockquote>
    <pre>DBL_DIG         DBL_MIN_EXP     FLT_MAX_EXP    LDBL_MANT_DIG
DBL_EPSILON     DECIMAL_DIG     FLT_MIN        LDBL_MAX_10_EXP
DBL_MANT_DIG    FLT_DIG         FLT_MIN_10_EXP LDBL_MAX_EXP
DBL_MAX         FLT_EPSILON     FLT_MIN_EXP    LDBL_MAX
DBL_MAX_10_EXP  FLT_EVAL_METHOD FLT_RADIX      LDBL_MIN
DBL_MAX_EXP     FLT_MANT_DIG    FLT_ROUNDS     LDBL_MIN_10_EXP
DBL_MIN FLT_MAX LDBL_DIG        LDBL_MIN_EXP
DBL_MIN_10_EXP  FLT_MAX_10_EXP  LDBL_EPSILON
<ins>DBL_HAS_SUBNORM FLT_HAS_SUBNORM LDBL_HAS_SUBNORM
DBL_DECIMAL_DIG FLT_DECIMAL_DIG LDBL_DECIMAL_DIG
DBL_TRUE_MIN    FLT_TRUE_MIN    LDBL_TRUE_MIN</ins></pre>
  </blockquote>
  <p>It looks like all the functionality
    represented by these new macros
    is already available from <code>numeric_limits</code>.</p>
  <p>Change references to C standard:</p>
  <blockquote>
    <p>See also: ISO C <del>7.1.5,</del> 5.2.4.2.2, 5.2.4.2.1.</p>
  </blockquote>
  <div class="new">
    <h3>18.4.1 &emsp; Header <code>&lt;cstdint></code> synopsys</h3>
    <p><em>The matter of editorial consistency
      will be handled under P0175.</em></p>
    <p>Change paragraph 2:</p>
    <blockquote>
      <p>The header defines all types and macros the same as
      <del>7.18 in the C standard</del>
	<ins>the Standard C library header<code>&lt;stdint.h></code></ins>.
      <del>[ <em>Note:</em>
	The macros defined by
      <code>&lt;cstdint></code> are provided unconditionally.
      In particular, the symbols <code>__STDC_LIMIT_MACROS</code>
	and <code>__STDC_CONSTANT_MACROS</code>
	(mentioned in footnotes 219, 220, and 222 in the C standard)
      play no role in C++. &mdash;<em>end note</em> ]</del></p>
    </blockquote>
  </div>
  <h3>18.5 &emsp; Start and termination</h3>
  <p>Change paragraph 12:</p>
  <blockquote>
    <p>... [ <em>Note:</em>
      The standard file buffers are not flushed.
      See: ISO C <del>7.20.4.4</del> <ins>7.22.4.5</ins>.
      &mdash;<em>end note</em> ]</p>
  </blockquote>
  <p>Change reference to C standard for paragraph 12:</p>
  <blockquote>
    <p>See also: ... ISO C <del>7.10.4</del> <ins>7.22.4</ins>.</p>
  </blockquote>
  <h3>18.6.2.4 &emsp; Data races</h3>
  <p>Change paragraph 1:</p>
  <blockquote>
    <p>For purposes of determining the existence of data races,
      the library versions of <code>operator new</code>,
      user replacement versions of global <code>operator new</code>,
      the C standard library functions
      <ins><code>aligned_alloc</code>,</ins>
      <code>calloc</code> and <code>malloc</code>,
      the library versions of <code>operator delete</code>,
      user replacement versions of <code>operator delete</code>,
      the C standard library function <code>free</code>,
      and the C standard library function <code>realloc</code>
      shall not introduce a data race (17.6.5.9).
      Calls to these functions
      that allocate or deallocate a particular unit of storage
      shall occur in a single total order,
      and each such deallocation call shall happen before (1.10)
      the next allocation (if any) in this order.</p>
  </blockquote>
  <p>18.6.2.1 also references <code>malloc</code>,
    and reference to <code>aligned_alloc</code>
    should be made as well;
    that issue is addressed in <a href="#p0035">P0035</a>.
  </p>
  <h3>18.10 &emsp; Other runtime support</h3>
  <p>Change reference to C standard for paragraph 3:</p>
  <blockquote>
    <p>See also: ISO C <del>4.8.1.1</del>
      <ins>7.16.1.1</ins>.</p>
  </blockquote>
  <p>Change references to C standard for paragraph 4:</p>
  <blockquote>
    <p>See also: ISO C <del>7.10.4, 7.8, 7.6,</del> <ins>7.13</ins> <del>7.12</del>.</p>
  </blockquote>
  <p>7.10.4 referred to the <code>exit</code> family of functions;
    7.8 to <code>&lt;stdarg.h&gt;</code>;
    and 7.12 (possibly) to <code>&lt;time.h&gt;</code>.
    These other references may be relevant elsewhere,
    but not to this paragraph,
    which is solely about <code>setjmp</code>
    and <code>longjmp</code>.</p>
  <h3>19.3 &emsp; Assertions</h3>
  <p>Change paragraph 3:</p>
  <blockquote>
    <p>The contents are the same as the Standard C library header
      <code>&lt;assert.h></code><ins>,
      except that a macro named <code>static_assert</code>
	is not defined in header
	<code>&lt;cassert&gt;</code>
	or in header <code>&lt;assert.h&gt;</code></ins>.</p>
  </blockquote>
  <p>Note: This kind of problem is handled
    in a slightly different way
    in 18.10p7-8.</p>
  <h3>20.9.13 &emsp; C library</h3>
  <p>Change table 48:</p>
  <blockquote>
    <pre>Functions: calloc malloc  <ins>aligned_alloc</ins>
           free   realloc</pre>
  </blockquote>
  <p>Change paragraph 3:</p>
  <blockquote>
    <p>The functions <ins><code>aligned_alloc()</code>,</ins>
      <code>calloc()</code>,
      <code>malloc()</code>, and <code>realloc()</code>
      do not attempt to allocate storage
    by calling <code>::operator new()</code> (18.6).</p>
  </blockquote>
  <p>Change the reference to the C standard for paragraph 4:</p>
  <blockquote>
    <p>See also: ISO C Clause <del>7.11.2</del> <ins>7.22.3</ins>.</p>
  </blockquote>
  <p>Change paragraph 5:</p>
  <blockquote>
    <p>Storage allocated directly
      with <ins><code>aligned_alloc()</code>,</ins>
      <code>malloc()</code>, <code>calloc()</code>,
      or <code>realloc()</code>
      is implicitly declared reachable (see 3.7.4.3) on allocation,
      ....</p>
  </blockquote>
  <p>Change the reference to the C standard for paragraph 7:</p>
  <blockquote>
    <p>See also: ISO C Clause <del>7.11.2</del> <ins>7.24</ins>.</p>
  </blockquote>
  <h3>20.15.8 &emsp; Date and time functions</h3>
  <p>Change table 63:</p>
  <blockquote>
    <pre>Macros: NULL   CLOCKS_PER_SEC <ins>TIME_UTC</ins>
Types:  size_t clock_t        time_t
Struct: tm     <ins>timespec</ins>
Functions:
asctime clock  difftime       localtime strftime
ctime   gmtime mktime         time      <ins>timespec_get</ins></pre>
  </blockquote>
  <p>Change the references to the C standard for paragraph 2:</p>
  <blockquote>
    <p>See also: ISO C Clause <del>7.12</del> <ins>7.27.</ins> <del>,
      Amendment 1 Clause 4.6.4.</del></p>
  </blockquote>
  <h3>21.5 &emsp; Null-terminated sequence utilities</h3>
  <p>Change the references to the C standard for paragraph 15:</p>
  <blockquote>
    <p>See also: ISO C <del>7.3, 7.10.7, 7.10.8, and 7.11.
      Amendment 1 4.4, 4.5, and 4.6</del>
      <ins>7.4, 7.22.7, 7.22.8, 7.24, 7.28, 7.29 and 7.30</ins>.</p>
  </blockquote>
  <h3>22.6 &emsp; C library locales</h3>
  <p>Change the reference to the C standard for paragraph 3:</p>
  <blockquote>
    <p>See also: ISO C Clause <del>7.4</del> <ins>7.11</ins>.</p>
  </blockquote>
  <h3>25.6 &emsp; C library algorithms</h3>
  <p>Change the reference to the C standard for paragraph 4:</p>
  <blockquote>
    <p>See also: ISO C Clause <del>7.10.5</del> <ins>7.22.5</ins>.</p>
  </blockquote>
  <h3>26.9 &emsp; C library</h3>
  <p>Change paragraph 1:</p>
  <blockquote>
    <p>The header <code>&lt;ctgmath></code>
      simply includes the headers
      <del><code>&lt;ccomplex></code></del>
      <ins><code>&lt;complex></code></ins>
      and <code>&lt;cmath></code>.</p>
  </blockquote>
  <p>Change paragraph 2:</p>
  <blockquote>
    <p>[ <em>Note:</em>
      The overloads provided in C by type-generic macros
      are already provided in
      <del><code>&lt;ccomplex></code></del>
      <ins><code>&lt;complex></code></ins>
      and <code>&lt;cmath></code>
      by &ldquo;sufficient&rdquo; additional overloads.
      &mdash;<em>end note</em> ]</p>
  </blockquote>
  <p>Change the references to the C standard for paragraph 15:</p>
  <blockquote>
    <p>See also: ISO C <del>7.5, 7.10.2, 7.10.6</del>
      <ins>7.12, 7.22.2, 7.22.6</ins>.</p>
  </blockquote>
  <h3>27.4.1 &emsp; Overview</h3>
  <p>Change paragraph 4:</p>
  <blockquote>
    <p>Mixing operations
      on corresponding wide- and narrow-character streams
      follows the same semantics as mixing such operations on FILEs,
      as specified in <del>Amendment 1 of</del>
      the ISO C standard.</p>
  </blockquote>
  <h3>27.11 &emsp; C library files</h3>
  <p>Change paragraph 1:</p>
  <blockquote>
    <p>Table 151 describes header <code>&lt;cstdio></code>.
      <del>[ <em>Note:</em>
	C++ does not define the function <code>gets</code>.
	&mdash;<em>end note</em> ]</del></p>
  </blockquote>
  <p>Add a new paragraph following paragraph 1:</p>
  <blockquote>
    <p><ins>The contents of this header
      are the same as the Standard C library header
      <code>&lt;stdio.h></code>.</ins></p>
  </blockquote>
  <p>Change table 151:</p>
  <blockquote>
    <pre>clearerr fopen   fsetpos putchar snprintf vscanf
fclose   fprintf ftell   puts    sprintf  vsnprintf
feof     fputc   fwrite  remove  sscanf   vsprintf
ferror   fputs   getc    rename  tmpfile  vsscanf
fflush   fread   getchar rewind  tmpnam   <ins>vfscanf</ins>
fgetc    freopen perror  scanf   ungetc
fgetpos  fscanf  printf  setbuf  vfprintf
fgets    fseek   putc    setvbuf vprintf</pre>
  </blockquote>
  <p>Change the references to the C standard for paragraph 2:</p>
  <blockquote>
    <p>See also: ISO C <del>7.9, Amendment 1 4.6.2</del>
      <ins>7.21</ins>.</p>
  </blockquote>
  <p>Change paragraph 3:</p>
  <blockquote>
    <p class="new">Table 152 describes header <code>&lt;cinttypes></code>.
      <del>[ <em>Note:</em>
	The macros defined by <code>&lt;cinttypes></code>
	are provided unconditionally.
      In particular, the symbol <code>__STDC_FORMAT_MACROS</code>,
      mentioned in footnote 182 of the C standard,
      plays no role in C++. &mdash;<em>end note</em> ]</del></p>
  </blockquote>
  <h3>D.3 &emsp; C standard library headers</h3>
  <p>Change paragraph 1:</p>
  <blockquote>
    <p>For compatibility with the C standard library
      <del>and the C Unicode TR</del>,
      the C++ standard library provides the 26 C headers,
      as shown in Table 154.</p>
  </blockquote>
  <p>Add a new paragraph:</p>
  <blockquote>
    <p class="new"><ins>The use of any of the C++ headers
      <code>&lt;ccomplex></code>,
      <code>&lt;cstdalign></code>,
      <code>&lt;cstdbool></code>,
      or <code>&lt;ctgmath></code>
      is deprecated.</ins></p>
  </blockquote>
  <p><em>The previous draft also suggested
    deleting the corresponding <code>&lt;*.h&gt;</code> headers,
    but that suggestion has been retracted.</em></p>
  <h2>Related proposals</h2>
  <dl>
    <dt><a id="p0035" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0035r1.html">P0035R1</a></dt>
    <dd>&ldquo;Dynamic memory allocation for over-aligned data&rdquo;,
      Clark Nelson</dd>
    <dt><a id="p0175" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0175r0.html">P0175R0</a></dt>
    <dd>&ldquo;Synopses for the C library&rdquo;,
      Thomas K&ouml;ppe, Richard Smith</dd>
    <dt><a id="p0270" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0270r0.html">P0270R0</a></dt>
    <dd>&ldquo;Removing C dependencies
      from signal handler wording&rdquo;, Hans-J. Boehm</dd>
  </dl>
</body>
</html>
