John Spicer <jhs_at_[hidden]> writes:

| On Oct 7, 2013, at 9:11 PM, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
|
| >
| > 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.
|
| In general, for compile-time things like these, I agree that undefined
| behavior is undesirable. Mostly because that implies that the
| program can do whatever it wants to if it gets to run-time.
|
| I think most of these came from cases where there was perceived to be
| the possibility of implementation variance based on the underlying
| mechanism used for things like preprocessing, and also to account for
| limitations of certain systems.
|
| I wonder if for some of these things we should basically say "you
| shouldn't do this, but if you do it is conditionally supported with
| implementation-defined behavior". That gives implementations freedom
| to accept or reject cases and allows for implementation variance in
| areas like the UCN line splice case without resulting in undefined
| behavior at runtime.

Hi John,

we don't have Standardese for "your shouldn't be doing this" :-)

Exactly modifications would you want to see "conditionallt-supported with
implementation-defined semantics" instead of "ill-formed"?

-- Gaby