Re: [C++ patch] Set attributes for C++ runtime library calls

[Mike Stump <mikestump at comcast dot net>]

On Aug 22, 2013, at 6:10 PM, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> I think we must distinguish what is "wrong" according to the standards
> we are implementing from what is "wrong" from a QoI point of view.

Not if they match, we don't.

> My reasoning (for C++98, but the same is true for C++11) is based
> on 3.8/1:
>   […]
>   The lifetime of an object of type T ends when:
>    -- if T is a class type with a non-trivial destructor (12.4),
>       the destructor call starts, or
>    --  the storage which the object occupies is reused or released.
> 
> Doing a placement-new on the storage occupied by 'a' is reusing
> its storage, therefore ending its lifetime.

The problem is that reused is not well defined, so, we are into the weeds right there.

int i, j;

int *ip = &i;

i = 1;
j = 2;
*ip = j;
++i;
++j;

here, we sees the storage being reused in the *ip = j; statement, or, is it merely changing the value?  And what if we do a memcpy (ip, &j, sizeof (int));  Is that reused, or merely changing the value.  I think the most logical line of reasoning is that when the requirements of [basic.lval] are met, the, this is a change of value of an object, not a modification to it's lifetime.  So, in the case quoted, since the type of the accesses are both int, we don't reuse the storage, since the requirements of [basic.lval] are met.  Indeed, the programmer expects that they can access i after *ip = j; and that the _value_ that object, while changed from the original 1, will be 2 just after the *ip = j; statement.

Since we know that i must be 3 at the end, we then know what the wording, reused, must mean, cause other meanings that could possibly make it work for you in the case you are considering, would destroy this property of pointers, and everyone knows the semantics of pointers, they are undisputed.  Or put another way, you cannot misread reused in this way.