Date: Mon, 7 Oct 2013 21:23:10 -0400
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.
John.
>
> -- Gaby
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>
> 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.
John.
>
> -- Gaby
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
Received on 2013-10-08 03:23:13