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.

John.

>
> -- Gaby
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub