<div dir="ltr">2.2/1: Forming a UCN through a line splice works in both implementations of UCNs that I know of (EDG&#39;s and Clang&#39;s). Making it ill-formed would invalidate these implementations. Same with forming a UCN through token concatenation. Suggestion: make this valid, to match existing implementations.<div>
<br></div><div>2.5/2: I&#39;m a little worried that people might be relying on this, for instance in macro arguments that are only ever stringized. I can&#39;t find an implementation that rejects this by default (though GCC and Clang reject it in their pedantic modes).</div>
<div><br></div><div>16.1/4: Should the case where &#39;defined&#39; is created through macro expansion make the program ill-formed, or should we specify its behavior? (The natural behavior seems to me to be that a &#39;defined&#39; token appearing through macro expansion should be treated like any other identifier, and be replaced by 0)</div>
<div><br></div><div>16.8/4: In some circumstances it is desirable to #undef __DATE__ and __TIME__ (if you want a deterministic, reproducible build). Are we OK with that making the program ill-formed?</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Oct 7, 2013 at 12:34 PM, W Brown <span dir="ltr">&lt;<a href="mailto:webrown.cpp@gmail.com" target="_blank">webrown.cpp@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Oct 7, 2013, at 1:42 PM, Gabriel Dos Reis wrote:<br>
<br>
&gt; At the evening session (Thursday September 26) at the Chicago meeting,<br>
&gt; there was a consensus expressed that erroneous preprocessor constructs<br>
&gt; should not be ground for undefined behavior.<br>
&gt;<br>
&gt; The attached PDF file is my current attempt at implementing that consensus.<br>
&gt; Please read and comment.  Suggestions for improvements, corrections welcome.<br>
<br>
<br>
</div></div>sec 3 para 1 typos:<br>
  &quot;the real&quot; -&gt; &quot;the realm&quot;<br>
  &quot;prescription&quot; -&gt; &quot;proscription&quot;<br>
<br>
sec 3 para 1 suggested rephrasing:<br>
  &quot;… a proscription (on the effect of certain potentially evaluated string literal expressions) that is outside …&quot;<br>
<br>
sec 2.2/6 and 2.3 suggestion:<br>
  make the literal more recognizable by stating it as a power of two minus one<br>
<br>
sec 3 para 2 suggested rephrasing:<br>
  &quot;… limit on the line-number explicitly recognizes an implicit constraint (on programs) that is best diagnosed …&quot;<br>
<br>
sec 2 title:  &quot;Changes&quot; -&gt; &quot;Proposed wording&quot;<br>
<br>
sec 1 para 2:  &quot;section §3&quot; -&gt; either &quot;section 3&quot; or &quot;§3&quot;<br>
<br>
sec 1 para 1:  &quot;At that meeting, the attendance felt strongly that …&quot; -&gt; &quot;Those attending that meeting felt strongly that …&quot; or &quot;That meeting&#39;s attendees felt strongly that …&quot;<br>
<br>
sec 2.3:  &quot;… in #line directive …&quot; -&gt; &quot;… in a #line directive …&quot;<br>
<br>
<br>
Best,<br>
<br>
-- WEB<br>
_______________________________________________<br>
ub mailing list<br>
<a href="mailto:ub@isocpp.open-std.org">ub@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/ub" target="_blank">http://www.open-std.org/mailman/listinfo/ub</a><br>
</blockquote></div><br></div>