<div dir="ltr">2.2/1: Forming a UCN through a line splice works in both implementations of UCNs that I know of (EDG's and Clang'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'm a little worried that people might be relying on this, for instance in macro arguments that are only ever stringized. I can'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 'defined' 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 'defined' 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"><<a href="mailto:webrown.cpp@gmail.com" target="_blank">webrown.cpp@gmail.com</a>></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>
> At the evening session (Thursday September 26) at the Chicago meeting,<br>
> there was a consensus expressed that erroneous preprocessor constructs<br>
> should not be ground for undefined behavior.<br>
><br>
> The attached PDF file is my current attempt at implementing that consensus.<br>
> Please read and comment. Suggestions for improvements, corrections welcome.<br>
<br>
<br>
</div></div>sec 3 para 1 typos:<br>
"the real" -> "the realm"<br>
"prescription" -> "proscription"<br>
<br>
sec 3 para 1 suggested rephrasing:<br>
"… a proscription (on the effect of certain potentially evaluated string literal expressions) that is outside …"<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>
"… limit on the line-number explicitly recognizes an implicit constraint (on programs) that is best diagnosed …"<br>
<br>
sec 2 title: "Changes" -> "Proposed wording"<br>
<br>
sec 1 para 2: "section §3" -> either "section 3" or "§3"<br>
<br>
sec 1 para 1: "At that meeting, the attendance felt strongly that …" -> "Those attending that meeting felt strongly that …" or "That meeting's attendees felt strongly that …"<br>
<br>
sec 2.3: "… in #line directive …" -> "… in a #line directive …"<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>