Gennaro Prota <[EMAIL PROTECTED]> writes: > On Sat, 25 Jan 2003 19:17:35 -0500, David Abrahams > <[EMAIL PROTECTED]> wrote: > >>It's hard for me to justify any other interpretations under a strict >>reading of the standard. > > Yes. > >>I am tempted to open a DR about this, but >>I'm not sure exactly how much we should ask for. Shooting for the >>moon, we could ask that an expression can only invoke undefined >>behavior if it is "potentially evaluated", c.f. 3.2/2 > > That solves the problem when you wrap the function call in a sizeof; > but leaves undefined behavior for Peter's example, where the call is > never performed. I would say that one should allow undefined behavior > only if the call is actually executed (I should rather say: when the > call-expression is actually evaluated, to take into account inlining. > But I'm trying to use a simpler language).
Well, that's shooting for Mars, or maybe even Pluto. > Basically I find that the standard is all but crystal clear when it > comes to the difference between a function-call expression (banally: > a sequence of "signs" written in the program text) and a function > call in its run-time meaning. Take for instance the beginning of > 5.2.2/4: > > > "When a function is called, each parameter (8.3.5) shall be > initialized (8.5, 12.8, 12.1) with its corresponding argument. > When a function is called, the parameters that have object type > shall have completely-defined object type." > > > It uses the phrase "When a function is called" two times: in the > second case it clearly refers to the function call expression, not to > the actual call of the function; so the "when" is to be interpreted as > "at the point of". In the first case I tend to think instead that it > refers to the run-time call, because initialization of function > parameters (as I intend it) is a run-time operation. Note in fact > that, immediately after, the standard says: > > " **During** the initialization of a parameter" > > IMHO trying to think initialization as a purely formal (and thus > compile-time) operation is a little problematic. Coming back to the > main point, I think that if the standard was more clear in the > distinction between a call and a call-expression we wouldn't have any > chance to ask ourselves whether > > f( non_pod ); > > is undefined or not: either the standard would say that writing the > function-call expression is undefined (thus even if it is in a > sizeof), or that actually calling the function is undefined. > Personally, I think it should be the second one and that Peter's > example should have a well-defined behavior. Hum. It's fine to make Peter's particular example defined, but I'm a little concerned about asking to lift *all* undefined behavior for expressions that aren't executed, since the definition of undefined behavior seems explicitly designed to allow during translation of certain constructs. Usually these things are done for a reason, though occasionally it's just "arbitrary implementor leeway". -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost