Additional note (November, 2019):

The resolution of issue 2382 effectively addresses the request in this issue by eliminating the array overhead in the case of the standard placement allocator.

EWG (January, 2021):

Resolved by issue 2382. See vote.

Rationale (February, 2012):

The CWG agreed that EWG is the appropriate venue for dealing with this issue.

Note, January, 2012:

It has been suggested that this issue is more appropriate for EWG and should thus be closed with "extension" status.

Notes from the April, 2005 meeting:

While the CWG agreed that there is no portable means to accomplish this task in the current language, they felt that a paper is needed to analyze the numerous mechanisms that might address the problem and advance a specific proposal. There is no volunteer to write such a paper at this time.

[Resolved by issue 2382, which was accepted as a DR at the November, 2019 meeting.]

(See also issue 256.)

An implementation may have an unspecified amount of array allocation overhead (7.6.2.8 [expr.new] paragraph 10), so that evaluation of a new-expression in which the new-type-id is T[n] involves a request for more than n * sizeof(T) bytes of storage through the relevant operator new[] function.

The placement operator new[] function does not and cannot check whether the requested size is less than or equal to the size of the provided region of memory (17.6.3.4 [new.delete.placement] paragraphs 5-6). A program using placement array new must calculate what the requested size will be in advance.

Therefore any program using placement array new must take into account the implementation's array allocation overhead, which cannot be obtained or calculated by any portable means.