John Spicer <jhs_at_[hidden]> writes:

| On Oct 7, 2013, at 10:02 PM, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
|
| > 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" :-)
|
| That could be in note :-)
|
| >
| > Exactly modifications would you want to see "conditionallt-supported with
| > implementation-defined semantics" instead of "ill-formed"?
|
| Yes.

Hmmm, I meant "give me a list of changes that you would like to see
marked as conditionally-supported with implementation-defined semantics."

-- Gaby