Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding

[Michael Matz <matz at suse dot de>]

Hi,

On Wed, 3 Feb 2010, Mark Mitchell 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.

> More formally, what I'm proposing is that if the static type is a
> character or array-of-character type, placement new simply constructs a
> new type.  Otherwise, it is as-if you do a delete/new and get back the
> same pointer value, modulo the fact that no destructor is run.

Or wait, would you then also disallow placement new onto individual 
subobjects of larger objects (be they char[] or not)?


Ciao,
Michael.