On 7 Oct 2013 19:38, "Thomas Plum" <tplum_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?
>
> All that is required by "making it ill-formed" is that a diagnostic
> message is required. The message could even praise the programmer:
> "Congratulations for using our special feature which splices UCN tokens."
> There are no requirements on the contents of the message, and it does
> warn the programmer that the construct is not portable.

But it is portable across all implementations of UCNs that I can find. Why
make them nonconforming and force them to detect this situation (which
might not be trivial to implement) rather than just defining the behaviour?

Making this ill formed, but expecting implementations to diagnose it and
accept, is just as bad as undefined behavior, because a program doing this
is still accepted and still does not have defined behavior.

If we really want to allow implementation variance, I think we should say
it's conditionally supported, but if the program is accepted, it must act
as a UCN. (And similarly for other cases.)

> > | 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...
>
> Agreed.
>
> > | 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.
>
> Agreed.
>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub