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 10:57 AM, Michael Matz <> 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

-- Gaby

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