<p dir="ltr"><br>
On 7 Oct 2013 19:38, "Thomas Plum" <<a href="mailto:tplum@plumhall.com">tplum@plumhall.com</a>> wrote:<br>
><br>
> > Thanks for the feedback. See comments below.<br>
> ><br>
> > Richard Smith <<a href="mailto:richardsmith@google.com">richardsmith@google.com</a>> writes:<br>
> ><br>
> > | 2.2/1: Forming a UCN through a line splice works in both<br>
> > implementations of<br>
> > | UCNs that I know of (EDG's and Clang's). Making it ill-formed would<br>
> > invalidate<br>
> > | these implementations. Same with forming a UCN through token<br>
> > concatenation.<br>
> > | Suggestion: make this valid, to match existing implementations.<br>
> ><br>
> > so, you want "implementation-defined" here?<br>
> > Do real programs actually rely on this working?<br>
><br>
> All that is required by "making it ill-formed" is that a diagnostic<br>
> message is required. The message could even praise the programmer:<br>
> "Congratulations for using our special feature which splices UCN tokens."<br>
> There are no requirements on the contents of the message, and it does<br>
> 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's conditionally supported, but if the program is accepted, it must act as a UCN. (And similarly for other cases.)</p>
<p dir="ltr">> > | 2.5/2: I'm a little worried that people might be relying on this, for<br>
> > instance<br>
> > | in macro arguments that are only ever stringized. I can't find an<br>
> > | implementation that rejects this by default (though GCC and Clang<br>
> > reject it in<br>
> > | their pedantic modes).<br>
> ><br>
> > the reason for suggesting this resolution is that it has worked well in<br>
> > pedantic modes on real programs. The only time I was made aware of a<br>
> > difference was with the "old K&R" preprocessor which worked on<br>
> > characters, not tokens -- GCC has had separate for that program anyway<br>
> > since the rework by both Zack and Neil, more than a decade ago.<br>
> ><br>
> > | 16.1/4: Should the case where 'defined' is created through macro<br>
> > expansion make<br>
> > | the program ill-formed, or should we specify its behavior? (The<br>
> > natural<br>
> > | behavior seems to me to be that a 'defined' token appearing through<br>
> > macro<br>
> > | expansion should be treated like any other identifier, and be<br>
> > replaced by 0)<br>
> ><br>
> > that, to me, is surprising; not natural :-)<br>
> > I did consider it, including an implementation-defined behavior, but<br>
> > concluded that just adds to the pile of non-portability with not much<br>
> > benefit...<br>
><br>
> Agreed.<br>
><br>
> > | 16.8/4: In some circumstances it is desirable to #undef __DATE__ and<br>
> > __TIME__<br>
> > | (if you want a deterministic, reproducible build). Are we OK with<br>
> > that making<br>
> > | the program ill-formed?<br>
> ><br>
> > I would think so. Implementations are still free to let their users to<br>
> > opt out.<br>
><br>
> Agreed.<br>
><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">http://www.open-std.org/mailman/listinfo/ub</a><br>
</p>