<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
	"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
  <title>Working draft changes for C99 preprocessor synchronization</title>
  <!-- -->
  <style type="text/css">
h1 { clear: right }
ins { text-decoration: underline }
del { display: inline; text-decoration: line-through }
code { font-style: normal }
var { font-family: serif }
.right { float: right }
.syntax { font-style: italic }
.prose { font-style: normal }
  </style>
  <!-- -->
</head>

<body>

<table class="right" summary="This table provides identifying information for this
		document.">
<tr>
<th>Doc. No.:</th>
<td>WG21/N1653<br />
J16/04-0093</td>
</tr>
<tr>
<th>Date:</th>
<td>2004-07-16</td>
</tr>
<tr>
<th>Reply to:</th>
<td>Clark Nelson</td>
</tr>
<tr>
<th>Phone:</th>
<td>+1-503-712-8433</td>
</tr>
<tr>
<th>Email:</th>
<td><a href="mailto:clark.nelson@intel.com">clark.nelson@intel.com</a></td>
</tr>
</table>
<h1>Working draft changes for C99 preprocessor synchronization</h1>

<p>This document details the changes that need to be made to the working draft 
  to resynchronize the preprocessor 
  and translation phases of C++ with C99, according to the consensus of the combined 
  Core and Evolution working group session at the Sydney meeting. Several areas 
  with differences are explicitly excluded at this time:</p>

<ul>
<li>Universal character names: This area will be explored in detail in a 
separate paper.</li>
<li>Standard pragmas: This area is considered to be part of the larger issue of 
floating-point differences, which should be considered as a whole (but <strong>when</strong> 
and <strong>by whom</strong>?).</li>
<li>Extended integer types and <code>long long</code>: This area is being handled 
by Steve Adamczyk.</li>
<li>Purely editorial changes made to C++: These will be presented to the C committee 
for their consideration.</li>
</ul>
<p>Differences caused by differing terminology and by technical considerations unique 
  to C++ are also not considered.</p>

<p>Most of the wording changes presented here are directly from C99, as of its TC1 
  (2001). The few exceptions, and anything about which I think there might be any 
  remaining question, are all pointed out by a <strong>Note:</strong>.</p>
<p>Because most of the changes are not new drafting, but already appear in a 
  published standard, this document probably needs little discussion. Because 
  the Evolution group has already decided to go in this direction, and whatever 
  issues remain are probably at the level of wording tweaks, it may be that 
  whatever discussion is needed would be more effectively handled in the Core 
  group. But to be on the safe side, this paper is directed to both groups.</p>

<p>It is my intention to continue doing textual comparisons between the C standard 
  and subsequent working drafts of the C++ standard, and thereby discover any errors 
  in the application of these changes, and also any changes that I may have inadvertently 
  missed.</p>

<h2>Predefined macros</h2>

<p><strong>Note:</strong> Sometime between 1989 and 1999, the C committee (or the 
  editor) decided to put the list of predefined macro names into alphabetical order. 
  Clearly, this was a strictly editorial change. Purely for the sake of facilitating 
  textual comparisons between the two standards, I would recommend that the list 
  be sorted in the C++ standard as well. But I do not present the necessary changes 
  here, and I do not deal in detail with the order of presentation of predefined 
  macro descriptions.</p>

<p>Insert in 16.81:</p>

<blockquote>
<dl>
<dt><ins><code>__STDC_HOSTED__</code></ins></dt>
<dd><ins>The integer constant <code>1</code> if the implementation is a hosted implementation 
or the integer constant <code>0</code> if it is not.</ins></dd>
</dl>
</blockquote>
<p>Insert new paragraph following 16.81:</p>

<blockquote>
<p><ins>The following macro names are conditionally defined by the implementation:</ins></p>

<dl>
<dt><code>__STDC__</code></dt>
<dd>Whether <code>__STDC__</code> is predefined and if so, what its value is, are 
implementation-defined.</dd>
<dt><ins><code>__STDC_VERSION__</code></ins></dt>
<dd><ins>Whether <code>__STDC_VERSION__</code> is predefined and if so, what its 
value is, are implementation-defined.</ins></dd>
<dt><ins><code>__STDC_ISO_10646__</code></ins></dt>
<dd><ins>An integer constant of the form <code>yyyymmL</code> (for example,
<code>199712L</code>), intended to indicate that values of type <code>wchar_t</code> 
are the coded representations of the characters defined by ISO/IEC 10646, along 
with all amendments and technical corrigenda as of the specified year and month.</ins></dd>
</dl>
</blockquote>
<p><strong>Note:</strong> I recommend moving the description of <code>__STDC__</code> 
  (unchanged) from 1 to 2, since it really is and always has been conditionally 
  defined in C++.</p>

<p>Change 16.83:</p>

<blockquote>
<p>If any of the pre-defined macro names in this subclause, or the identifier
  <code>defined</code>, is the subject of a <code>#define</code> or a <code>#undef</code> 
  preprocessing directive, the behavior is undefined. <ins><em>[Note:</em> Any other 
  predefined macro names shall begin with a leading underscore followed by an uppercase 
  letter or a second underscore. <em>--end note]</em></ins></p>

</blockquote>
<p><strong>Note:</strong> The added sentence is in C99, and a slightly different 
  version was in C89. I believe that the sentence was deleted from C++ because of 
  general reluctance on the part of the editor to use the word &quot;shall&quot; to impose 
  a requirement on an implementation. It is also possible that it was believed that 
  this sentence was redundant with the rules for reserved names in 17.4.3.1. In 
  any event, I recommend adding the sentence (back), as it appears in C99; I believe 
  both these possible objections are addressed by making it a non-normative note.</p>

<h2>Pragma operator</h2>

<p>Change 16.3.43:</p>

<blockquote>
<p>The resulting completely macro-replaced preprocessing token sequence is not processed 
  as a preprocessing directive even if it resembles one<ins>, but all pragma unary 
  operator expressions within it are then processed as specified in 16.9 below</ins>.</p>

</blockquote>
<p>Insert new section 16.9:</p>

<blockquote>
<p><ins><strong>16.9 Pragma operator</strong></ins></p>

<p><ins>A unary operator expression of the form:</ins></p>

<blockquote>
<p><ins><code>_Pragma (</code> <var>string-literal</var> <code>)</code></ins></p>

</blockquote>
<p><ins>is processed as follows: The string literal is <dfn>destringized</dfn> by 
  deleting the <code>L</code> prefix, if present, deleting the leading and trailing 
  double-quotes, replacing each escape sequence <code>\&quot;</code> by a double-quote, 
  and replacing each escape sequence <code>\\</code> by a single backslash. The 
  resulting sequence of characters is processed through translation phase 3 to produce 
  preprocessing tokens that are executed as if they were the <var>pp-tokens</var> 
  in a pragma directive. The original four preprocessing tokens in the unary operator 
  expression are removed.</ins></p>

<p><ins><em>[Example:</em> A directive of the form:</ins></p>

<blockquote>
<pre><span><ins>#pragma listing on &quot;..\listing.dir&quot;</ins></span></pre>
</blockquote>
<p><ins>can also be expressed as:</ins></p>

<blockquote>
<pre><span><ins>_Pragma ( &quot;listing on \&quot;..\\listing.dir\&quot;&quot; )</ins></span></pre>
</blockquote>
<p><ins>The latter form is processed in the same way whether it appears literally 
  as shown, or results from macro replacement, as in:</ins></p>

<blockquote>
<pre><span><ins>#define LISTING(x) PRAGMA(listing on #x)
#define PRAGMA(x) _Pragma(#x)

LISTING ( ..\listing.dir )</ins></span></pre>
</blockquote>
</blockquote>
<p>Change 2.1 phase 4:</p>

<blockquote>
<p>Preprocessing directives are executed<ins>,</ins> <del>and</del> macro invocations 
  are expanded<ins>, and <code>_Pragma</code> unary operator expressions are executed</ins>. 
  If a character sequence that matches the syntax of a universal character name 
  is produced by token concatenation (16.3.3), the behavior is undefined. A
  <code>#include</code> preprocessing directive causes the named header or source 
  file to be processed from phase 1 through phase 4, recursively. <ins>All preprocessing 
  directives are then deleted.</ins></p>

</blockquote>
<h2>Variadic macros and empty macro arguments</h2>

<p>Change the definition of <var>control-line</var> (161):</p>

<blockquote>
<dl class="syntax">
<dt>control-line:</dt>
<dd><code># include</code> pp-tokens new-line</dd>
<dd><code># define</code> identifier replacement-list new-line</dd>
<dd><code># define</code> identifier lparen identifier-list<sub>opt</sub> <code>
)</code> replacement-list new-line</dd>
<dd><ins><code># define</code> identifier lparen <code>... )</code> replacement-list 
new-line</ins></dd>
<dd><ins><code># define</code> identifier lparen identifier-list <code>, ... )</code> 
replacement-list new-line</ins></dd>
<dd><code># undef</code> identifier new-line</dd>
<dd><code># line</code> pp-tokens new-line</dd>
<dd><code># error</code> pp-tokens<sub>opt</sub> new-line</dd>
<dd><code># pragma</code> pp-tokens<sub>opt</sub> new-line</dd>
<dd><code>#</code> new-line</dd>
</dl>
</blockquote>
<p>Change 16.34:</p>

<blockquote>
<p><ins>If the identifier-list in the macro definition does not end with an ellipsis,</ins> 
  the number of arguments <ins>(including those arguments consisting of no preprocessing 
  tokens)</ins> in an invocation of a function-like macro shall <del>agree with</del>
  <ins>equal</ins> the number of parameters in the macro definition<ins>.</ins><del>, 
  and</del> <ins>Otherwise, there shall be more arguments in the invocation than 
  there are parameters in the macro definition (excluding the <code>...</code>).</ins> 
  There shall exist a <code>)</code> preprocessing token that terminates the invocation.</p>

</blockquote>
<p>Insert new paragraph following 16.34:</p>

<blockquote>
<p><ins>The identifier <code>__VA_ARGS__</code> shall occur only in the replacement-list 
  of a function-like macro that uses the ellipsis notation in the parameters.</ins></p>

</blockquote>
<p>Change 16.39:</p>

<blockquote>
<p>A preprocessing directive of the form</p>

<dl class="syntax">
<dd><code># define</code> identifier lparen identifier-list<sub>opt</sub> <code>
)</code> replacement-list new-line</dd>
<dd><ins><code># define</code> identifier lparen <code>... )</code> replacement-list 
new-line</ins></dd>
<dd><ins><code># define</code> identifier lparen identifier-list <code>, ... )</code> 
replacement-list new-line</ins></dd>
</dl>
<p>defines a <del>function-like macro</del> <ins><dfn>function-like macro</dfn></ins> 
  with parameters, <em>etc.</em></p>

</blockquote>
<p><strong>Note:</strong> This change incorporates part of a move of the definition 
  of the term &quot;function-like macro&quot;; the rest of the move is presented below as 
  a minor wording tweak. The confusion of presenting the changes in this way is 
  hoped to be less than the confusion of presenting overlapping changes independently.</p>

<p>Change 16.310:</p>

<blockquote>
<p>The sequence of preprocessing tokens bounded by the outside-most matching parentheses 
  forms the list of arguments for the function-like macro. The individual arguments 
  within the list are separated by comma preprocessing tokens, but comma preprocessing 
  tokens between matching inner parentheses do not separate arguments. <del>If (before 
  argument substitution) any argument consists of no preprocessing tokens, the behavior 
  is undefined.</del> If there are sequences of preprocessing tokens within the 
  list of arguments that would otherwise act as preprocessing directives, the behavior 
  is undefined.</p>

</blockquote>
<p>Insert new paragraph after 16.310:</p>

<blockquote>
<p><ins>If there is a <code>...</code> in the identifier-list in the macro definition, 
  then the trailing arguments, including any separating comma preprocessing tokens, 
  are merged to form a single item: the variable arguments. The number of arguments 
  so combined is such that, following merger, the number of arguments is one more 
  than the number of parameters in the macro definition (excluding the <code>...</code>).</ins></p>

</blockquote>
<p>Insert new paragraph after 16.3.11:</p>

<blockquote>
<p><ins>An identifier <code>__VA_ARGS__</code> that occurs in the replacement list 
  shall be treated as if it were a parameter, and the variable arguments shall form 
  the preprocessing tokens used to replace it.</ins></p>

</blockquote>
<p>Insert new sentence in 16.3.22:</p>

<blockquote>
<p><em>....</em> If the replacement that results is not a valid character string 
  literal, the behavior is undefined. <ins>The character string literal corresponding 
  to an empty argument is <code>&quot;&quot;</code>.</ins> The order of evaluation of
  <code>#</code> and <code>##</code> operators is unspecified.</p>

</blockquote>
<p>Change 16.3.32:</p>

<blockquote>
<p>If, in the replacement list <ins>of a function-like macro</ins>, a parameter 
  is immediately preceded or followed by a ## preprocessing token, the parameter 
  is replaced by the corresponding argument&#39;s preprocessing token sequence<ins>; 
  however, if an argument consists of no preprocessing tokens, the parameter is 
  replaced by a placemarker preprocessing token instead.<em>Footnote</em></ins></p>

<p><em>Footnote:</em> Placemarker preprocessing tokens do not appear in the syntax 
  because they are temporary entities that exist only within translation phase 4.</p>

</blockquote>
<p>Change 16.3.33:</p>

<blockquote>
<p>For both object-like and function-like macro invocations, before the replacement 
  list is reexamined for more macro names to replace, each instance of a ## preprocessing 
  token in the replacement list (not from an argument) is deleted and the preceding 
  preprocessing token is concatenated with the following preprocessing token.
  <ins>Placemarker preprocessing tokens are handled specially: concatenation of 
  two placemarkers results in a single placemarker preprocessing token, and concatenation 
  of a placemarker with a non-placemarker preprocessing token results in the non-placemarker 
  preprocessing token.</ins> If the result is not a valid preprocessing token, the 
  behavior is undefined. The resulting token is available for further macro replacement. 
  The order of evaluation of ## operators is unspecified.</p>

</blockquote>
<p>Insert new paragraph following 16.3.33:</p>

<blockquote>
<p><ins><em>[Example:</em> In the following fragment:</ins></p>

<blockquote>
<pre><span><ins>#define hash_hash # ## #
#define mkstr(a) # a
#define in_between(a) mkstr(a)
#define join(c, d) in_between(c hash_hash d)
char p[] = join(x, y); // <em>equivalent to</em>
                       // char p[] = &quot;x ## y&quot;;</ins></span></pre>
</blockquote>
<p><ins>The expansion produces, at various stages:</ins></p>

<blockquote>
<pre><span><ins>join(x, y)
in_between(x hash_hash y) 
in_between(x ## y)
mkstr(x ## y)
&quot;x ## y&quot;</ins></span></pre>
</blockquote>
<p><ins>In other words, expanding <code>hash_hash</code> produces a new token, consisting 
  of two adjacent sharp signs, but this new token is not the <code>##</code> operator.
  <em>--end example]</em></ins></p>

</blockquote>
<p>Change 16.3.55:</p>

<blockquote>
<p>To illustrate the rules for redefinition and reexamination, the sequence</p>

<blockquote>
<pre>#define x 3
#define f(a) f(x * (a))
#undef x
#define x 2
#define g f
#define z z[0]
#define h g(~
#define m(a) a(w)
#define w 0,1
#define t(a) a
<span><ins>#define p() int
#define q(x) x
#define r(x,y) x ## y
#define str(x) # x</ins></span>

f(y+1) + f(f(z)) % t(t(g)(0) + t)(1);
g(x+(3,4)-w) | h 5) &amp; m
      (f)^m(m);
<span><ins>p() i[q()] = { q(1), r(2,3), r(4,), r(,5), r(,) };
char c[2][6] = { str(hello), str() };</ins></span></pre>
</blockquote>
<p>results in</p>

<blockquote>
<pre>f(2 * (y+1)) + f(2 * (f(2 * (z[0])))) % f(2 * (0)) + t(1);
f(2 * (2+(3,4)-0,1)) | f(2 * (~ 5)) &amp; f(2 * (0,1))^m(0,1);
<span><ins>int i[] = { 1, 23, 4, 5, };
char c[2][6] = { &quot;hello&quot;, &quot;&quot; };</ins></span></pre>
</blockquote>
</blockquote>
<p>Insert new paragraph after 16.3.56:</p>

<blockquote>
<p><ins>To illustrate the rules for placemarker preprocessing tokens, the sequence</ins></p>

<blockquote>
<pre><span><ins>#define t(x,y,z) x ## y ## z
int j[] = { t(1,2,3), t(,4,5), t(6,,7), t(8,9,),
t(10,,), t(,11,), t(,,12), t(,,) };</ins></span></pre>
</blockquote>
<p><ins>results in</ins></p>

<blockquote>
<pre><span><ins>int j[] = { 123, 45, 67, 89,
10, 11, 12, };</ins></span></pre>
</blockquote>
</blockquote>
<p>Insert new paragraph after 16.3.57:</p>

<blockquote>
<p><ins>Finally, to show the variable argument list macro facilities:</ins></p>

<blockquote>
<pre><span><ins>#define debug(...) fprintf(stderr, __VA_ARGS__)
#define showlist(...) puts(#__VA_ARGS__)
#define report(test, ...) ((test)?puts(#test):\
            printf(__VA_ARGS__))
debug(&quot;Flag&quot;);
debug(&quot;X = %d\n&quot;, x);
showlist(The first, second, and third items.);
report(x&gt;y, &quot;x is %d but y is %d&quot;, x, y);</ins></span></pre>
</blockquote>
<p><ins>results in</ins></p>

<blockquote>
<pre><span><ins>fprintf(stderr, &quot;Flag&quot; );
fprintf(stderr, &quot;X = %d\n&quot;, x );
puts( &quot;The first, second, and third items.&quot; );
((x&gt;y)?puts(&quot;x&gt;y&quot;):
           printf(&quot;x is %d but y is %d&quot;, x, y));</ins></span></pre>
</blockquote>
</blockquote>
<h2>String literal concatenation</h2>

<p>Change 2.1 phase 6:</p>

<blockquote>
<p>Adjacent <del>ordinary</del> string literal tokens are concatenated. <del>Adjacent 
  wide string literal tokens are concatenated.</del></p>

</blockquote>
<p>Change 2.13.43:</p>

<blockquote>
<p>In translation phase 6 (2.1), adjacent <del>narrow</del> string literals are 
  concatenated <del>and adjacent wide string literals are concatenated</del>. If 
  a narrow string literal token is adjacent to a wide string literal token, the
  <del>behavior is undefined</del> <ins>result is a wide string literal</ins>. Characters 
  in concatenated strings are kept distinct. <em>[Example: etc.</em></p>

</blockquote>
<h2>Header and include file names</h2>

<p><strong>Note:</strong> In investigating this issue since the Sydney meeting, 
  I discovered that C++ (unintentionally, I&#39;m morally certain) includes UCNs in 
  the set of portable elements of header and source file names, by virtue of referencing 
  the non-terminal <var>nondigit</var>. The simplest solution to this problem would 
  be to adopt C99&#39;s grammar for identifiers, by changing the rules in 2.10, preceding 
  1:</p>

<blockquote>
<dl class="syntax">
<dt>identifier:</dt>
<dd><del>nondigit</del> <ins>identifier-nondigit</ins></dd>
<dd>identifier <del>nondigit</del> <ins>identifier-nondigit</ins></dd>
<dd>identifier digit</dd>
</dl>
<dl class="syntax">
<dt><ins>identifier-nondigit</ins></dt>
<dd><ins>nondigit</ins></dd>
<dd><ins>universal-character-name</ins></dd>
<dd><ins><span class="prose">other implementation-defined characters</span></ins></dd>
</dl>
<dl class="syntax">
<dt>nondigit: <span class="prose">one of</span></dt>
<dd><del>universal-character-name</del></dd>
<dd><code>_ a b c d e f g h i j k l m</code></dd>
<dd><code>n o p q r s t u v w x y z</code></dd>
<dd><code>A B C D E F G H I J K L M</code></dd>
<dd><code>N O P Q R S T U V W X Y Z</code></dd>
</dl>
<dl class="syntax">
<dt>digit: <span class="prose">one of</span></dt>
<dd><code>0 1 2 3 4 5 6 7 8 9</code></dd>
</dl>
</blockquote>
<p>Change 16.25:</p>

<blockquote>
<p><del>The mapping between the delimited sequence and the external source file 
  name is implementation-defined.</del> The implementation provides unique mappings 
  for sequences consisting of one or more <var>nondigits</var> <ins>or <var>digits</var></ins> 
  (2.10) followed by a period (.) and a single <var>nondigit</var>. <ins>The first 
  character shall not be a <var>digit</var>.</ins> The implementation may ignore 
  the distinctions of alphabetical case.</p>

</blockquote>
<p><strong>Note:</strong> This is the only area where logically overlapping changes 
  were made from C89 in both C99 and C++. This formulation matches what I will be 
  proposing to the C committee, but of course I can&#39;t guarantee that it will be accepted in 
  precisely this form.</p>

<h2>Translation limit changes</h2>

<p>Change the last sentence of 16.43:</p>

<blockquote>
<p>If the digit sequence specifies zero or a number greater than <del>32767</del>
  <ins>2147483647</ins>, the behavior is undefined.</p>

</blockquote>
<h2>Editorial changes</h2>

<h3>Clarifying phases of translation</h3>

<p>Change 161:</p>

<blockquote>
<p>A preprocessing directive consists of a sequence of preprocessing tokens. The 
  first token in the sequence is a <code>#</code> preprocessing token that <ins>
  (at the start of translation phase 4)</ins> is either the first character in the 
  source file (optionally after white space containing no new-line characters) or 
  that follows white space containing at least one new-line character. The last 
  token in the sequence is the first new-line character that follows the first token 
  in the sequence.<sup>138)</sup> <ins>A new-line character ends the preprocessing 
  directive even if it occurs within what would otherwise be an invocation of a 
  function-like macro.</ins></p>

</blockquote>
<p>Insert new example immediately before 16.1:</p>

<blockquote>
<p><ins><em>[Example:</em> In:</ins></p>

<blockquote>
<pre><span><ins>#define EMPTY
EMPTY # include &lt;file.h&gt;</ins></span></pre>
</blockquote>
<p><ins>the sequence of preprocessing tokens on the second line is <em>not</em> 
  a preprocessing directive, because it does not begin with a <code>#</code> at 
  the start of translation phase 4, even though it will do so after the macro
  <code>EMPTY</code> has been replaced. <em>-- end example]</em></ins></p>

</blockquote>
<h3>Clarifying the definition of directive</h3>

<p>Change the definition of <var>group-part</var> (16):</p>

<blockquote>
<dl class="syntax">
<dt>group-part:</dt>
<dd><del>pp-tokens<sub>opt</sub> new-line</del></dd>
<dd>if-section</dd>
<dd>control-line</dd>
<dd><ins>text-line</ins></dd>
<dd><ins><code>#</code> non-directive</ins></dd>
<dd></dd>
</dl>
</blockquote>
<p>Insert definitions before <var>lparen</var>:</p>

<blockquote>
<dl class="syntax">
<dt><ins>text-line:</ins></dt>
<dd><ins>pp-tokens<sub>opt</sub> new-line</ins></dd>
</dl>
<dl class="syntax">
<dt><ins>non-directive:</ins></dt>
<dd><ins>pp-tokens new-line</ins></dd>
</dl>
</blockquote>
<p>Insert two new paragraphs before 162:</p>

<blockquote>
<p><ins>A text line shall not begin with a <code>#</code> preprocessing token. A 
  non-directive shall not begin with any of the directive names appearing in the 
  syntax.</ins></p>

<p><ins>When in a group that is skipped (16.1), the directive syntax is relaxed 
  to allow any sequence of preprocessing tokens to occur between the directive name 
  and the following new-line character.</ins></p>

</blockquote>
<h3>Clarifying macro names with extended characters</h3>

<p>Insert new paragraph before 16.33:</p>

<blockquote>
<p><ins>There shall be white-space between the identifier and the replacement list 
  in the definition of an object-like macro.</ins></p>

</blockquote>
<p><strong>Rationale:</strong> Consider the following example:</p>

<blockquote>
<pre>#define A$B c</pre>
</blockquote>
<p>In an implementation which allows <code>$</code> as an identifier character, 
  this is clearly a definition of a macro named <code>A$B</code>. In an implementation 
  which does not allow <code>$</code> in an identifier, this could have been taken 
  as a definition of a macro named <code>A</code>, with the <code>$</code> interpreted 
  as the first pp-token of the definition, without emitting a diagnostic. With this 
  change, the second implementation would be required to issue a diagnostic (this 
  paragraph is a constraint in C99).</p>

<h3>Clarifying precedence of token-pasting and stringizing</h3>

<p>Change 16.3.41:</p>

<blockquote>
<p>After all parameters in the replacement list have been substituted <ins>and
  <code>#</code> and <code>##</code> processing has taken place, all placemarker 
  preprocessing tokens are removed. Then,</ins> the resulting preprocessing token 
  sequence is rescanned<ins>, along</ins> with all subsequent preprocessing tokens 
  of the source file<ins>,</ins> for more macro names to replace.</p>

</blockquote>
<h3>Clarifying &quot;scope&quot; of macros within phases of translation</h3>

<p>Insert a new sentence at the end of 16.3.51:</p>

<blockquote>
<p>A macro definition lasts (independent of block structure) until a corresponding
  <code>#undef</code> directive is encountered or (if none is encountered) until 
  the end of the <ins>preprocessing</ins> translation unit. <ins>Macro definitions 
  have no significance after translation phase 4.</ins></p>

</blockquote>
<p><strong>Note:</strong> This paragraph contains one of the very few uses of the term 
  &quot;preprocessing translation unit&quot;, which is new in C99, and is effectively equivalent 
  to &quot;translation unit&quot;, but applies during preprocessing (basically translation 
  phase 4). If that term is not to be introduced into C++ (concerning which I have 
  no strong feelings), the word &quot;preprocessing&quot; should not be inserted as directed 
  above.</p>

<h3>Clarifying the possible effects of a pragma</h3>

<p>Change 16.61:</p>

<blockquote>
<p>A preprocessing directive of the form</p>

<blockquote>
<pre># pragma <var>pp-tokens<sub>opt</sub> new-line</var></pre>
</blockquote>
<p>causes the implementation to behave in an implementation-defined manner. <ins>
  The behavior might cause translation to fail or cause the translator or the resulting 
  program to behave in a non-conforming manner.</ins> Any pragma that is not recognized 
  by the implementation is ignored.</p>

</blockquote>
<p><strong>Note:</strong> In C99, this paragraph is also modified for the sake of 
  standard pragmas. Those modifications are not presented here.</p>

<h3>Clarifying line-splicing</h3>

<p>Change 2.1 phase 2:</p>

<blockquote>
<p>Each instance of a <del>new-line character and an immediately preceding backslash 
  character</del> <ins>a backslash character (<code>\</code>) immediately followed 
  by a new-line character</ins> is deleted, splicing physical source lines to form 
  logical source lines. <ins>Only the last backslash on any physical source line 
  shall be eligible for being part of such a splice.</ins> If, as a result, a character 
  sequence that matches the syntax of a universal-character-name is produced, the 
  behavior is undefined. If a source file that is not empty does not end in a new-line 
  character, or ends in a new-line character immediately preceded by a backslash 
  character <ins>before any such splicing takes place</ins>, the behavior is undefined.</p>

</blockquote>
<p><strong>Note:</strong> The statement about forming a UCN-like sequence is unique 
  to C++, and will be reviewed in that context.</p>

<h3>Clarifying the mapping to the execution character set</h3>

<p>Change 2.1 phase 5:</p>

<blockquote>
<p>Each source character set member, escape sequence, or universal-character-name 
  in character literals and string literals is converted to <del>a</del> <ins>the 
  corresponding</ins> member of the execution character set (2.13.2, 2.13.4)<ins>; 
  if there is no corresponding member, it is converted to an implementation-defined 
  member other than the null (wide) character<em>Footnote</em></ins>.</p>

<p><ins><em>Footnote:</em> An implementation need not convert all non-corresponding 
  source characters to the same execution character.</ins></p>

</blockquote>
<h3>Minor wording tweaks</h3>

<p>Change the definition of <var>lparen</var> (16):</p>

<blockquote>
<dl class="syntax">
<dt>lparen:</dt>
<dd><del><span class="prose">the left-parenthesis character without preceding white-space</span></del></dd>
<dd><ins><span class="prose">a <code>(</code> character not immediately preceded 
by white-space</span></ins></dd>
</dl>
</blockquote>
<p>Change the last sentence of 16.11:</p>

<blockquote>
<p><em>...</em> which evaluate to <code>1</code> if the identifier is currently 
  defined as a macro name (that is, if it is predefined or if it has been the subject 
  of a <code>#define</code> preprocessing directive without an intervening <code>
  #undef</code> directive with the same subject identifier), <del>zero</del>
  <ins><code>0</code></ins> if it is not.</p>

</blockquote>
<p>Change and combine 16.32-3:</p>

<blockquote>
<p>An identifier currently defined as <del>a macro without use of lparen (</del>an 
  object-like macro<del>)</del> may be redefined by another <code>#define</code> 
  preprocessing directive provided that the second definition is an object-like 
  macro definition and the two replacement lists are identical, otherwise the program 
  is ill-formed. <del><em>break</em> An</del> <ins>Likewise, an</ins> identifier 
  currently defined as <del>a macro using lparen (</del>a function-like macro<del>)</del> 
  may be redefined by another <code>#define</code> preprocessing directive provided 
  that the second definition is a function-like macro definition that has the same 
  number and spelling of parameters, and the two replacement lists are identical, 
  otherwise the program is ill-formed.</p>

</blockquote>
<p>Change 16.38:</p>

<blockquote>
<p>A preprocessing directive of the form</p>

<blockquote>
<pre># define <var>identifier replacement-list new-line</var></pre>
</blockquote>
<p>defines an <del>object-like macro</del> <ins><dfn>object-like macro</dfn></ins> 
  that causes <em>etc.</em></p>

</blockquote>
<p><strong>Note:</strong> The combination of the previous two changes with the change 
  presented above to 16.39 (under variadic macros) move the definitions of the 
  terms &quot;object-like macro&quot; and &quot;function-like macro&quot; forward in the text. In C99, 
  they are moved from Constraints paragraphs to Semantics paragraphs.</p>

<p>Change the last sentence of 16.3.11:</p>

<blockquote>
<p><em>....</em> Before being substituted, each argument&#8217;s preprocessing tokens 
  are completely macro replaced as if they formed the rest of the <del>translation 
  unit</del> <ins>preprocessing file</ins>; no other preprocessing tokens are available.</p>

</blockquote>
<p>Change 16.3.42:</p>

<blockquote>
<p>If the name of the macro being replaced is found during this scan of the replacement 
  list (not including the rest of the source file&#8217;s preprocessing tokens), it is 
  not replaced. <del>Further</del> <ins>Furthermore</ins>, if any nested replacements 
  encounter the name of the macro being replaced, it is not replaced. <em>etc.</em></p>

</blockquote>
<p>Change 16.3.56:</p>

<blockquote>
<pre><em>...</em>
#define debug(s, t) printf(&quot;x&quot; # s &quot;= %d, x&quot; # t &quot;= %s&quot;, \
				x ## s, x ## t)
#define INCFILE(n) vers ## n <span><del>/* from previous #include example */</del></span>
#define glue(a, b) a ## b
<em>...</em></pre>
</blockquote>
<p>Change 2.1 phase 3:</p>

<blockquote>
<p><em>...</em> A source file shall not end in a partial preprocessing token or
  <ins>in a</ins> partial comment. <em>...</em></p>

</blockquote>
<p>Change 2.1 phase 7:</p>

<blockquote>
<p>White-space characters separating tokens are no longer significant. Each preprocessing 
  token is converted into a token. (2.6). The resulting tokens are syntactically 
  and semantically analyzed and translated <ins>as a translation unit</ins>. <em>
  [Note: etc.</em></p>

</blockquote>
<p>And finally, change almost all comments in examples in 16 from &quot;C-style&quot; to 
  &quot;C++-style&quot;. The only exceptions are in the valid redefinitions in 16.4.57, 
  which demonstrate the redefinition rules, and which depend on white space within 
  the macro definition. The detailed changes are left as an editorial exercise.</p>

</body>

</html>
