<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
 "http://www.w3.org/TR/html4/strict.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<title>P0063R0: C++17 should refer to C11 instead of C99</title>
</head>
<body>
<table>
	<tr>
                <th>Doc. No.:</th>
                <td>WG21/P0063R0</td>
        </tr>
        <tr>
                <th>Date:</th>
                <td>2015-09-25</td>
        </tr>
        <tr>
                <th>Authors:</th>
                <td>Hans-J. Boehm, Clark Nelson</td>
        </tr>
        <tr>
                <th>Email:</th>
                <td><a href="mailto:hboehm@google.com">hboehm@google.com</a></td>
        </tr>
</table>
	
<h1>P0063R0: C++17 should refer to C11 instead of C99</h1>

<p>
We propose to have the C++ working document refer to C11 instead of C99.  There
appears to be little disagreement that this is fundamentally a good idea.  The
current situation creates several problems:
</p>
<ul>
<li> C99 is not the current C standard.  By 2017 implementations should support
C++17 and C11.  C99 will be increasingly irrelevant.  Interoperation of C11 and
C++17 will be what matters.</li>
<li>By ignoring C11, we hide a number of important issues, including the
interoperation of C11’s threads and atomic operations APIs with their C++
counterparts.  These issues are increasingly important to both users and
implementers.  Interoperability was a major design goal of the C++11
facilities, but it cannot be realized without implementation consistency in
this area.</li>
<li>Much more specifically and concretely, the effect of including
<code>&lt;cstdalign&gt;</code> is not well specified.  The current claim is
that it does substantially the same thing as including
<code>&lt;stdalign.h&gt;</code>, but that header is described only in C11.
(The same is not true of <code>&lt;cuchar&gt;</code>.  The
<code>&lt;uchar.h&gt;</code> header is also new in C11 as compared with C99,
but it was originally specified in the “new character data types” TR (19769),
and for it the C++ standard refers to that specification.)</li>
</ul>
<p>
Tom Plum wrote a prior paper:
</p>
<blockquote>
<p><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3631.pdf">
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3631.pdf</a></p>
</blockquote>
<p>
outlining changes in C11 and possible C++ impact.
</p>

<h2>Outline</h2>
<p>
This proposal has three parts:
</p>
<ul>
<li><a href="#easy">The easy part: Replace the normative reference.</a></li>
<li><a href="#repair">Repair the resulting breakage.</a></li>
<li><a href="#optional">Optionally address C11 interoperability issues we've
previously ignored.</a></li>
</ul>

<h2><a name="easy">The easy part</a></h2>
<p>
Update  1.2 [intro.refs] p1.3:
</p>

<blockquote>
<p>(1.3) — ISO/IEC 9899:<del>1999</del><ins>2011</ins>, Programming languages — C</p>
</blockquote>

<p>
Update 1.2 [intro.refs] p2:
</p>

<blockquote>
<p>
(2) The library described in Clause 7 of ISO/IEC
9899:<del>1999</del><ins>2011</ins> and Clause 7 of ISO/IEC
9899:<del>1999</del><ins>2011</ins>/Cor.1:<del>2001</del><ins>2012</ins>
<del>and Clause 7 of ISO/IEC 9899:1999/Cor.2:2003</del> is hereinafter called
the C standard library.<sup>1</sup>
</p>
</blockquote>

<h2><a name="repair">Repair the resulting breakage</a></h2>
<p>
Since we generally don't blanket include C features, there seems to be
little that is directly broken by the above change.
The one issue we are aware of is:
</p>

<h3>Signal handlers</h3>
<p>
We need to make it clear that <code>thread_local</code>, and possibly
other C11 extensions, remain unsupported in signal handlers.
This will otherwise implicitly change when we refer to C11, since a POF
("plain old function") is defined in terms of C.
<p>
Richard Smith points out that the current POF definition has other
issues.  However, we believe its intent is generally reasonably understood.
Failing to change the wording here would clearly mis-state our intent:
Allowing <code>thread_local</code> in signal handlers was discussed by
SG1 and rejected.
<p>
The signal handler definitions currently also rely in some subtle ways on the
fact that atomic operations are function calls.  We don't expect that to
change, though particularly drastic approaches to accommodating C11
atomics might change it.
</p>

<h2><a name="optional">Address interoperability issues</a></h2>

<h3>Various C headers</h3>
<p>
As mentioned above, referring to C11, resolves a current issue with
<code>stdalign.h</code>.
<p>
We are not required to say anything about other new C headers, since the
supported ones are explicitly listed in 18.10 [support.runtime].  By default,
we simply don't support others.
<p>
However, as we discuss below, in some cases silence leaves some significant
practical issues unresolved.
<p>
Some minor issues are listed here.  More major ones are listed below.
</p>

<ul>
<li>There is no equivalent of <code>stdnoreturn.h</code>.</li>

<li>The standard C++ library provides no facility for dynamically allocating
memory with a specified alignment (<code>aligned_alloc</code>).</li>

<li>The standard C++ library does not provide the <code>timespec</code> facility
for querying fine-grained clock time.</li>

<li>The <code>&lt;cmath&gt;</code> header does not define macros for
<code>HAS_SUBNORM</code>, <code>TRUE_MIN</code>, or <code>DECIMAL_DIG</code>
for each floating type.</li>

<li>The <code>&lt;cassert&gt;</code> header does not define a macro named
<code>static_assert</code> expanding to <code>_Static_assert</code>.</li>

</ul>

<h3>Optional components</h3>
<p>
C11 has several optional components, notably threads, atomics, and the annex K
bounds-checking interfaces.  C++ has traditionally resisted optional
components.  If we decide that we want to address interoperability with some of
these components, we will have to address that issue.
</p>

<h3>Clause 29: Atomics</h3>
<p>
It would be immensely helpful for many of us to make the interaction with C11
atomics clear.
<p>
Here is a straw-man proposal approximately reflecting the current Android
(since Lollipop) implementation:
<p>
<code>_Atomic</code> is not part of the C++ core language.
<p>
Including <code>cstdatomic</code> in C++ code has the effect of:
</p>
<ol>
<li>Including <code>&lt;atomic&gt;</code>
<li>Promoting all definitions in the C header to global namespace
<li><code>#define _Atomic(T) atomic&lt;T&gt;</code>
</ol>
<p>
Note that this effectively requires that C and C++ atomics be layout and
ABI compatible, something we can’t, and hopefully don’t need to, require.
</p>

<h3>Clause 30: Threads</h3>
<p>
Do we want to say anything to enable interoperability of C threads and
synchronization with C++ threads?
<p>
Do we want to somehow encourage C threads to be usable as C++ threads?
<p>
C and C++ don't agree on a common mutex type that could be used in a header
included from both C and C++ code.  Do we want to allow a <code>mtx_t</code> to be declared
in C++ code?  Should there be a wrapper object <code>c_mutex_t</code>, whose
constructor takes a pointer to a C <code>mtx_t</code>, such that the resulting
object meets C++ mutex requirements?  (Perhaps we also need a
<code>c_recursive_mutex_t</code>.)
</p>

<h2>Other C interoperability issues</h2>
<p>The following were discovered while investigating this topic, but
are not directly related to the move to C11:
<p>
The description of the <code>&lt;cstdio&gt;</code> header is flawed.  There is
a table that mentions the names that are supposed to be defined and declared –
but <code>&lt;stdio.h&gt;</code> from the C standard is not mentioned anywhere,
so technically there is no specification of what any of those names is supposed
to mean.  Also, the table doesn&#39;t mention the <code>vfscanf</code> function
at all.</p>

<p>
The description of <code>&lt;cfenv&gt;</code> is inconsistent
with those of all the other C headers.  It references the C standard by clause
number instead of header name, and includes declarations for all the functions,
in addition to taking them from the C standard by reference.  </p>

</body>
</html>
