This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Wed, Feb 3, 2010 at 8:04 AM, Michael Matz <> wrote:
> 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.

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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]