Proposed resolution:

This wording is relative to N3376.

1. Change Table 27 — "Descriptive variable definitions" in [allocator.requirements]:

   Table 27 — Descriptive variable definitions

   Variable	Definition
   u	a value of type YY::const_pointer obtained by calling YY::allocate, or else nullptrXX::const_void_pointer obtained by conversion from a result value of YY::allocate, or else a value of type (possibly const) std::nullptr_t.

[ 2013-04-20 Bristol ]

[ 2012-10 Portland: Move to Ready ]

No strong feeling that this is a big issue, but consensus that the proposed resolution is strictly better than the current wording, so move to Ready.

According to Table 28 — "Allocator requirements", the expression

a.allocate(n, u)

expects as second argument a value u that is described in Table 27 as:

a value of type YY::const_pointer obtained by calling YY::allocate, or else nullptr.

This description leaves it open, whether or whether not a value of type YY::const_void_pointer is valid or not. The corresponding wording in C++03 is nearly the same, but in C++03 there did not exist the concept of a general void_pointer for allocators. There is some evidence for support of void pointers because the general allocator_traits template declares

static pointer allocate(Alloc& a, size_type n, const_void_pointer hint);

and the corresponding function for std::allocator<T> is declared as:

pointer allocate(size_type, allocator<void>::const_pointer hint = 0);

As an additional minor wording glitch (especially when comparing with the NullablePointer requirements imposed on const_pointer and const_void_pointer), the wording seems to exclude lvalues of type std::nullptr_t, which looks like an unwanted artifact to me.