Re: [boost] Re: is_convertible corner case

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-26 12:50:13

Gennaro Prota <gennaro_prota_at_[hidden]> writes:

> On Sat, 25 Jan 2003 19:17:35 -0500, David Abrahams
> <dave_at_[hidden]> 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
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution