Re: Placement new[] weirdness

[Andrey Slepuhin <pooh at msu dot ru>]

On 15-Jul-99 Mike Stump wrote:
>> 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.

???
I.e. you want to say, that having p=0xbffff710 placement new
receives 0xbffff714? I don't believe.
Look below.

GNU gdb 4.17.0.11 with Linux support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) br __vn__FUiPv
Breakpoint 1 at 0x80487d4
(gdb) run
Starting program: /local/users/pooh/work/libp++/a.out 
Breakpoint 1 at 0x4004b3a4
0xbffff6e4

Breakpoint 1, 0x4004b3a4 in operator new [] (place=0xbffff6e4)
(gdb) cont
Continuing.
0xbffff6e8

Program exited normally.

So passed value differs from returned.

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

Agree. This was done intentionally for testcase.

>  Though, I agree with you, y should
> be mandated to be zero, bug in the Standard.

This is separate topic. And there will be implementation problems,
though this is possible.

> 
> Thanks for the testcase, it helps focus on the relevant and let us see
> exactly what you mean.

Sorry for bothering you.

Best regards,
Andrey.