Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c++ > #408

Re: Defect Report: Default Array-placement-new unusable due to unknowable memory requirement

From Daniel Krügler<daniel.kruegler@googlemail.com>
Newsgroups comp.std.c++
Subject Re: Defect Report: Default Array-placement-new unusable due to unknowable memory requirement
Date 2012-01-13 08:44 -0800
Organization A noiseless patient Spider
Message-ID <jenc6i$mrs$1@dont-email.me> (permalink)
References <4F05231E.2050400@googlemail.com>

Show all headers | View raw


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                      ]

Back to comp.std.c++ | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Defect Report: Default Array-placement-new unusable due to unknowable   memory requirement Louis Delacroix<joedoefawnbuck@gmail.com> - 2012-01-05 13:54 -0800
  Re: Defect Report: Default Array-placement-new unusable due to unknowable    memory requirement Daniel Krügler<daniel.kruegler@googlemail.com> - 2012-01-13 08:44 -0800
    Re: Defect Report: Default Array-placement-new unusable due to   unknowable    memory requirement yoursecretsaresafe@googlemail.com - 2013-01-12 11:24 -0800
      Re: Defect Report: Default Array-placement-new unusable due to unknowable memory requirement Daniel Krügler <daniel.kruegler@googlemail.com> - 2013-01-13 14:34 -0600

csiph-web