This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Placement new[] weirdness
- To: pooh at msu dot ru
- Subject: Re: Placement new[] weirdness
- From: mrs at wrs dot com (Mike Stump)
- Date: Thu, 15 Jul 1999 15:49:40 -0700
- Cc: egcs at egcs dot cygnus dot com
> Date: Fri, 16 Jul 1999 02:25:46 +0400 (MEDT)
> From: Andrey Slepuhin <pooh@msu.ru>
> To: (Mike Stump) <mrs@wrs.com>
> Cc: egcs@egcs.cygnus.com
> On 15-Jul-99 Mike Stump wrote:
> [snip]
> > Yes, bug you failed to mention a single problem (in the form of a
> > testcase) that you have. Sorry, we cannot help you without one.
> Well, the following program:
> #include <iostream>
> #include <new>
> struct X
> {
> X()
> {}
> ~X()
> {}
> };
> void main ()
> {
> #define N 5
> char p[N*sizeof(X)];
> cout<<(void*)p<<endl;
> X* p1=new(p) X[N];
> cout<<p1<<endl;
> }
> prints on i586-unknown-linux-gnu:
> 0xbffff710
> 0xbffff714
> This seems to be not conforming to C++ draft, clause 18.4.1.3
> (though conforming to 5.3.4).
What part does not conform to 18.4.1.3? 0xbffff714 is passed to the
placement new, and that value is returned. A proof would show some
other value being passed to it. Please show that.
> Accessing data of array p1 may lead to stack corruption.
That is your fault. Try double d[100], and no problems should occur
(even though it is not portable). Though, I agree with you, y should
be mandated to be zero, bug in the Standard.
Thanks for the testcase, it helps focus on the relevant and let us see
exactly what you mean.