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

> > 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] ?).


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