This is the mail archive of the gcc-patches@gcc.gnu.org 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 9:02 AM, Michael Matz <matz@suse.de> wrote:
> 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.

Yes.  This is so that (1) could be done, e.g. running the destructor.
(returning storage is secondary in this case.)
If you look through the standard, you will see that there is a
requirement on the user not to place itself in a position where
a destructor would have to be run on a non-existent object, once
he or she has already reused the previous object's storage.
See 3.8/3.

> 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.

Yes, but I still do not see what the real problem is.
Would you mind clarifying?


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