This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

3044. Strange specification of max_size() for an allocator

Section: [allocator.requirements] Status: New Submitter: Jon Cohen Opened: 2017-12-06 Last modified: 2018-01-29

Priority: 3

View other active issues in [allocator.requirements].

View all other issues in [allocator.requirements].

View all issues with New status.


Table 31 in the C++17 standard specifies X::max_size() (where X is an allocator type) as "The largest value that can meaningfully be passed to X::allocate()". Noticeably missing is the statement "Throws: Nothing".

As an example of why this is an issue, note that vector::max_size() and allocator_traits::max_size() are both marked noexcept. We must then interpret max_size() as being allowed to sometimes call std::terminate, or else {vector, allocator_traits, ...}::max_size() must be allowed to directly calculate numeric_limits<size_type>::max() / sizeof(value_type) instead of querying the allocator, even if Alloc::max_size() exists. This seems like a bug in the wording for the requirements of max_size() in an allocator type. I think an issue should be opened on this subject to add Throws: Nothing or similar to the requirements of max_size() for an allocator.

As an example consider writing up a framework to test the exception-safety of types in a given framework, since they were all written in an exception-free environment. One of the types in the framework is an allocator which, in a controlled way, can throw an exception at any point where it is allowed by the standard. It's important that the test framework be as pedantic as possible, so the allocator type throws on max_size(), since it is currently allowed to by the standard. When a reasonable vector implementation (at least those in libstdc++ and msvc) is, for example, asked to construct a vector from an initializer_list, it will call allocator_traits<Alloc>::max_size(), which will terminate the program because the exception thrown in Alloc::max_size() propagated through the noexcept traits function. Although this is conformant behavior, I think it's a bug in the standard that a function as benign as max_size() can terminate the program in this manner, and I think the fix is that a conformant allocator should be required to supply a non-throwing max_size() member function.


This problem was shortly discussed during review of LWG 2162 (see comment 2012-08-05). At that time the more drastic but also more consistent requirement that an allocator's max_size function shall not throw exceptions has not been added. IMO this position should be reconsidered to follow the spirit of the new issue LWG 3044.

[2018-01; Priority set to 3 after mailing list discussion]

Proposed resolution: