<p dir="ltr"><br>
On 7 Oct 2013 19:38, &quot;Thomas Plum&quot; &lt;<a href="mailto:tplum@plumhall.com">tplum@plumhall.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Thanks for the feedback.  See comments below.<br>
&gt; &gt;<br>
&gt; &gt; Richard Smith &lt;<a href="mailto:richardsmith@google.com">richardsmith@google.com</a>&gt; writes:<br>
&gt; &gt;<br>
&gt; &gt; | 2.2/1: Forming a UCN through a line splice works in both<br>
&gt; &gt; implementations of<br>
&gt; &gt; | UCNs that I know of (EDG&#39;s and Clang&#39;s). Making it ill-formed would<br>
&gt; &gt; invalidate<br>
&gt; &gt; | these implementations. Same with forming a UCN through token<br>
&gt; &gt; concatenation.<br>
&gt; &gt; | Suggestion: make this valid, to match existing implementations.<br>
&gt; &gt;<br>
&gt; &gt; so, you want &quot;implementation-defined&quot; here?<br>
&gt; &gt; Do real programs actually rely on this working?<br>
&gt;<br>
&gt; All that is required by &quot;making it ill-formed&quot; is that a diagnostic<br>
&gt; message is required.  The message could even praise the programmer:<br>
&gt; &quot;Congratulations for using our special feature which splices UCN tokens.&quot;<br>
&gt; There are no requirements on the contents of the message, and it does<br>
&gt; warn the programmer that the construct is not portable.</p>
<p dir="ltr">But it is portable across all implementations of UCNs that I can find. Why make them nonconforming and force them to detect this situation (which might not be trivial to implement) rather than just defining the behaviour?</p>

<p dir="ltr">Making this ill formed, but expecting implementations to diagnose it and accept, is just as bad as undefined behavior, because a program doing this is still accepted and still does not have defined behavior.</p>

<p dir="ltr">If we really want to allow implementation variance, I think we should say it&#39;s conditionally supported, but if the program is accepted, it must act as a UCN. (And similarly for other cases.)</p>
<p dir="ltr">&gt; &gt; | 2.5/2: I&#39;m a little worried that people might be relying on this, for<br>
&gt; &gt; instance<br>
&gt; &gt; | in macro arguments that are only ever stringized. I can&#39;t find an<br>
&gt; &gt; | implementation that rejects this by default (though GCC and Clang<br>
&gt; &gt; reject it in<br>
&gt; &gt; | their pedantic modes).<br>
&gt; &gt;<br>
&gt; &gt; the reason for suggesting this resolution is that it has worked well in<br>
&gt; &gt; pedantic modes on real programs.  The only time I was made aware of a<br>
&gt; &gt; difference was with the &quot;old K&amp;R&quot; preprocessor which worked on<br>
&gt; &gt; characters, not tokens -- GCC has had separate for that program anyway<br>
&gt; &gt; since the rework by both Zack and Neil, more than a decade ago.<br>
&gt; &gt;<br>
&gt; &gt; | 16.1/4: Should the case where &#39;defined&#39; is created through macro<br>
&gt; &gt; expansion make<br>
&gt; &gt; | the program ill-formed, or should we specify its behavior? (The<br>
&gt; &gt; natural<br>
&gt; &gt; | behavior seems to me to be that a &#39;defined&#39; token appearing through<br>
&gt; &gt; macro<br>
&gt; &gt; | expansion should be treated like any other identifier, and be<br>
&gt; &gt; replaced by 0)<br>
&gt; &gt;<br>
&gt; &gt; that, to me, is surprising; not natural :-)<br>
&gt; &gt; I did consider it, including an implementation-defined behavior, but<br>
&gt; &gt; concluded that just adds to the pile of non-portability with not much<br>
&gt; &gt; benefit...<br>
&gt;<br>
&gt; Agreed.<br>
&gt;<br>
&gt; &gt; | 16.8/4: In some circumstances it is desirable to #undef __DATE__ and<br>
&gt; &gt; __TIME__<br>
&gt; &gt; | (if you want a deterministic, reproducible build). Are we OK with<br>
&gt; &gt; that making<br>
&gt; &gt; | the program ill-formed?<br>
&gt; &gt;<br>
&gt; &gt; I would think so.  Implementations are still free to let their users to<br>
&gt; &gt; opt out.<br>
&gt;<br>
&gt; Agreed.<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; ub mailing list<br>
&gt; <a href="mailto:ub@isocpp.open-std.org">ub@isocpp.open-std.org</a><br>
&gt; <a href="http://www.open-std.org/mailman/listinfo/ub">http://www.open-std.org/mailman/listinfo/ub</a><br>
</p>