Thanks for the feedback. See comments below.

Richard Smith <richardsmith_at_[hidden]> writes:

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

so, you want "implementation-defined" here?
Do real programs actually rely on this working?

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

the reason for suggesting this resolution is that it has worked well in
pedantic modes on real programs. The only time I was made aware of a
difference was with the "old K&R" preprocessor which worked on
characters, not tokens -- GCC has had separate for that program anyway
since the rework by both Zack and Neil, more than a decade ago.

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

that, to me, is surprising; not natural :-)
I did consider it, including an implementation-defined behavior, but
concluded that just adds to the pile of non-portability with not much
benefit...

| 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?

I would think so. Implementations are still free to let their users to
opt out.

-- Gaby