[PATCH] Fix C++ strict-aliasing issues with memcpy folding
Michael Matz
matz@suse.de
Wed Feb 3 15:02:00 GMT 2010
Hi,
On Wed, 3 Feb 2010, Gabriel Dos Reis wrote:
> >> > If the placement new to part of an object makes the object go away, a
> >> > delete of it would be undefined (5.3.5/2). Â Hence I wouldn't be able to
> >> > deallocate storage in the above example with a 'delete p' at the end. Â I
> >> > wouldn't be able to deallocate it with 'delete f' either (to see this
> >> > replace the above placement new with 'f = new (&p->mem[1]) float;'
> >> > making f point into the middle of the storage of *p).
> >> >
> >> > This surprising effect doesn't depend on the declared storage type, it
> >> > breaks just as well if X.mem would be a char[8].
> >>
> >> Sure, that's true. Â But, since char[] is special, there's no need for my
> >> as-if. Â In the case of char[], you are permitted just to splat a new
> >> type on type of the storage.
> >
> > Hmm, I'm not sure I'm making myself clear. Â I am wondering about the
> > impossibility to delete such storage after placement new did its work,
> > char[] or not, if placement new implicitely destroys the surrounding
> > object.
>
> Hmm, I'm having trouble seeing the impossibility.
>
> delete p;
>
> does two things
>
> (1) run a destructor for the objected pointed to by 'p';
> after which, the object ceases to exist.
> (2) return storage back to the system
>
> which of (1) or (2) appears impossible?
5.3.5/2 says that in 'delete p', if it's an object delete (not array
delete), then p must be either: null, pointing to an object, or a base
subobject of an object.
Now, if you say (as you did upthread) that object *p ceased to exist with
the placement new, then p doesn't point to an object anymore, hence
'delete p' is undefined.
Ciao,
Michael.
More information about the Gcc-patches
mailing list