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.

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).

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)

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?


On Mon, Oct 7, 2013 at 12:34 PM, W Brown <webrown.cpp_at_[hidden]> wrote:

> On Oct 7, 2013, at 1:42 PM, Gabriel Dos Reis wrote:
>
> > At the evening session (Thursday September 26) at the Chicago meeting,
> > there was a consensus expressed that erroneous preprocessor constructs
> > should not be ground for undefined behavior.
> >
> > The attached PDF file is my current attempt at implementing that
> consensus.
> > Please read and comment. Suggestions for improvements, corrections
> welcome.
>
>
> sec 3 para 1 typos:
> "the real" -> "the realm"
> "prescription" -> "proscription"
>
> sec 3 para 1 suggested rephrasing:
> "… a proscription (on the effect of certain potentially evaluated string
> literal expressions) that is outside …"
>
> sec 2.2/6 and 2.3 suggestion:
> make the literal more recognizable by stating it as a power of two minus
> one
>
> sec 3 para 2 suggested rephrasing:
> "… limit on the line-number explicitly recognizes an implicit constraint
> (on programs) that is best diagnosed …"
>
> sec 2 title: "Changes" -> "Proposed wording"
>
> sec 1 para 2: "section §3" -> either "section 3" or "§3"
>
> 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 …"
>
> sec 2.3: "… in #line directive …" -> "… in a #line directive …"
>
>
> Best,
>
> -- WEB
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>