[ub] Remove undefined behavior from the preprocessor

Gabriel Dos Reis gdr at axiomatics.org
Tue Oct 8 04:02:57 CEST 2013


John Spicer <jhs at edg.com> writes:

| On Oct 7, 2013, at 9:11 PM, Gabriel Dos Reis <gdr at axiomatics.org> wrote:
| 
| > 
| > Thanks for the feedback.  See comments below.
| > 
| > Richard Smith <richardsmith at google.com> 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


More information about the ub mailing list