Re: More function decorations II (pool_allocator, mt_allocator, debug, stl_list)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Wed, Apr 22, 2009 at 8:16 AM, Richard Guenther <rguenther@suse.de> wrote:
> On Wed, 22 Apr 2009, Gabriel Dos Reis wrote:
>
>> On Wed, Apr 22, 2009 at 5:08 AM, Richard Guenther <rguenther@suse.de> wrote:
>> >
>> >> I believe there are unclear aspects of ?the reasoning. ?For example,
>> >> ?the pointer returned by the allocated as described above meets
>> >> the standard semantics, yet is also pointing into the statically
>> >> allocated object; no?
>> >
>> > Yes, so? ?The malloc attribute is a way to prune the points-to set
>> > based on language semantics that says that the returned object
>> > during its lifetime does not alias with other objects. ?So,
>> >
>> > char storage[...];
>> >
>> > T *p = new T();
>> > tmp = storage[0];
>> >
>> > invokes undefined behavior if p points to storage[0].
>>
>> Where does the C++ standard say that?
>
> 3.8/2
>
> "the lifetime of an array object or of an object of type ...
> and its lifetime ends when the storage with the array or object
> occupies is _reused_ or released" (emphasis mine)
>
> and /1 for when the lifetime of T() starts (which is the point
> storage[]s storage is reused).

However, that is only half of the story.
You also have to take into account that the explicit
permission of accessing objects (3.10/15) with lvalue expressions of
character types.  The above snippet does not change the
content of the object storage, it complies with 3.10/15 and
I do not think it is a reuse.

>
>> >?This is just
>> > the same as
>> >
>> > union { int i; float f; } u;
>> >
>> > u.i = 1;
>> > tmp = u.f;
>>
>> I'm missing the chapter and verse that says that.
>
> 6.5/7 (C standard). ?int and float are not compatible types.

Thanks, I'm familiar with the union case.
My comment was that there is no chapter and verse that
equates the two case.


>
>> > which invokes undefined behavior as well (ok, GCC has a language
>> > extension that makes it valid, but it is not a strictly conforming
>> > program). ?If you end u.i lifetime by
>> >
>> > u.f = 0;
>> >
>> > then you can read from u.f (obviously).
>>
>> I believe the union case is a completely different case
>> (GCC extension notwithstanding).
>
> Maybe. ?This is the only overlap of C and C++ where C exhibits
> a dynamic effective type for an object with a declared type.

Yes, but they also share this:

    struct Complex {
       double re;
       double im;
    };

    Complex* newComplex() {
       Complex* p = (Complex*) malloc(sizeof (Complex));
       p->re = 0;
       p-> im = 0;
    }

    int main(void) {
       Complex* p = newComplex();
       *(double*)p = 9.0;     // #1
        return p->im;
    }

I don't think #1 ends the lifetime of  the object pointed to by
`p' either.  The point here is that you have to factor in together
all the various places that allow accessing an object value
with different types other than the dynamic of effective types.
(3.10/15 in particular).

-- Gaby