This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding
On Wed, Feb 3, 2010 at 10:57 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Wed, 3 Feb 2010, Gabriel Dos Reis wrote:
>
>> > Okay. ?It's awkward, but correct. ?I just hope that every user of
>> > libraries that internally use placement new know that for some
>> > returned object pointers they must not delete them, but use 'operator
>> > delete' to just release storage.
>>
>> A user experienced enough to start using placement new is expected to be
>> experienced enough to know the distinction between that and a
>> new-expression. ?Consequently, the distinction between a
>> delete-expression and calling a destructor, or releasing memory. ?If
>> not, then, well the user should not be doing that in the first place.
>
> Yeah, but I'm talking about library users, when the library uses placement
> new internally, and the user might not be aware of this.
I am having trouble with this abstract setting.
Could you give a concrete example of such libraries?
The library that is pervasively used in modern C++
(the C++ standard library) takes pain at hidden placement new
from users and also makes explicit statement about
object managements.
Do you have a specific example of C++ libraries?
>
>> > Another question: The program from last mail again:
>> >
>> > struct X { int count; char mem[8]; } *p;
>> > p = new X;
>> > ... ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?// e.g. init all members of *p
>> > float *f = new (&p->mem[0]) float;
>> > *f = 1.0;
>> >
>> > Is it allowed to access p->count after this assignment to float?
>>
>> If we make the special exception for arrays of characters
>> (which means 'just storage to hold objects'), then the
>> access to p->count is OK.
>
> Um, so the placement new above does not in fact destroy *p? ?It's the same
> example from two mails ago, where you were agreeing that it does destroy
> *p. ?(And yes, I wanted to construct an example where the access was
> invalid, perhaps by making the .mem member have type int[2] ?).
As I said, there is an exception made for arrays of characters and
arrays of anything else. I know Mark said he could live with that
even though he would prefer a much stronger requirements.
However, my exemption for arrays of characters is twofold:
(1) they have always had exemption in terms of aliasing
(2) custom allocators are useful and should be allowed.
I do not see any of those reasons to apply for other types.
Anyway, an email I just got from the CWG indicates that this
whole discussion may be moot: reusing storage was not
intended to be permitted for object of different types. So, your
example with 'int[2]' will be invalid. I'll forward that message
shortly.
-- Gaby