This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding
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) 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.
> 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
> 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)?