> Unless I'm mistaken, you are describing
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#476
>
> in a pretty good way. The April 2005 notes indicate that the committee
> would prefer a paper that analyses the problem and a suggests a solution
> out of this problem. If anyone is willing to write such a paper please
> contact me.

I'm not sure if you got my last message. I would be very interested in writing this up; would you like to collaborate on this? I could draft an initial version. Is there a template format one should follow?

Thanks!


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Summary: The following code can never be correct:

     #include<new>

     void * addr = ???
     T * p = ::new (addr) T[N];

The problem is that it is impossible to know how much memory to allocate for addr at ???.


Details:

This problem was most recently highlighted by StackOverflow user MooingDuck, and adherent community discussion, in this
question:

http://stackoverflow.com/q/8720425/596781

The problem stems from two requirements of the standard. The first is that the default placement-new expression for
arrays calls the default placement-array-new allocation function:

     void * operator new[](std::size_t n, void * ptr);

Now 18.6.1.3/1 requires that this simply return ptr (i.e. "addr" in our example).

But the core problem comes from 5.3.4/12, which says that any conforming implementation is free to turn the "new"
expression from the example into a call to:

     p1 = ::operator new[](sizeof(T) * N + y, addr);

Here "y" is allowed to be any non-negative number which may differ for every invocation! Finally, p will be p1 + y, and
p1 == addr by the previous clause.

Thus construction of the T-objects starts at an *unspecified* and *unknowable* offset further down the allocated memory.
Since it is impossible to know the size of the offset y, it is also impossible to allocate the correct amount of memory,
and thus to use array-placement-new.

Note: This *only* affects the *default* version of the *global* array-placement-new. It is understood that other
placement versions may be endowed with additional size parameters that allow for safe checking.


The defect and its resolution:

The defect is that "y" is allowed to be non-zero for the global default array-placement-new expression. This should be
resolved by adding sentence to the standard that guarantees that the default global array-placement-new expression calls
::operator new[](sizeof(T) * N, ptr) without any addition.


I look forward to your opinions and feedback!

Best wishes,

Louis


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Am 05.01.2012 22:54, schrieb Louis Delacroix:
>  Summary: The following code can never be correct:
>
>        #include<new>
>
>        void * addr = ???
>        T * p = ::new (addr) T[N];
>
>  The problem is that it is impossible to know how much memory to allocate for addr at ???.
>
>
>  Details:
>
>  This problem was most recently highlighted by StackOverflow user MooingDuck, and adherent community discussion, in this
>  question:
>
>  http://stackoverflow.com/q/8720425/596781
>
>  The problem stems from two requirements of the standard. The first is that the default placement-new expression for
>  arrays calls the default placement-array-new allocation function:
>
>        void * operator new[](std::size_t n, void * ptr);
>
>  Now 18.6.1.3/1 requires that this simply return ptr (i.e. "addr" in our example).
>
>  But the core problem comes from 5.3.4/12, which says that any conforming implementation is free to turn the "new"
>  expression from the example into a call to:
>
>        p1 = ::operator new[](sizeof(T) * N + y, addr);
>
>  Here "y" is allowed to be any non-negative number which may differ for every invocation! Finally, p will be p1 + y, and
>  p1 == addr by the previous clause.
>
>  Thus construction of the T-objects starts at an *unspecified* and *unknowable* offset further down the allocated memory.
>  Since it is impossible to know the size of the offset y, it is also impossible to allocate the correct amount of memory,
>  and thus to use array-placement-new.
>
>  Note: This *only* affects the *default* version of the *global* array-placement-new. It is understood that other
>  placement versions may be endowed with additional size parameters that allow for safe checking.
>
>
>  The defect and its resolution:
>
>  The defect is that "y" is allowed to be non-zero for the global default array-placement-new expression. This should be
>  resolved by adding sentence to the standard that guarantees that the default global array-placement-new expression calls
>  ::operator new[](sizeof(T) * N, ptr) without any addition.
>
>
>  I look forward to your opinions and feedback!

Unless I'm mistaken, you are describing

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#476

in a pretty good way. The April 2005 notes indicate that the committee
would prefer a paper that analyses the problem and a suggests a solution
out of this problem. If anyone is willing to write such a paper please
contact me.

Greetings from Bremen,

Daniel Kr   gler



--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]