[Bug libstdc++/86189] not equal allocators not behaving as expected

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86189

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> Your allocators *always* compare unequal to all other instances of the same
> allocator. This is invalid, a copy-constructed allocator must compare equal
> to the original, and be able to deallocate its memory.

See the rows defining equality comparison and copy construction at
http://en.cppreference.com/w/cpp/named_req/Allocator#Requirements

Allocator propagation rules do not mean that the same specific instance of the
allocator must be used for all allocations and deallocation, only one that
compares equal to the original one. With your allocator that's obviously
impossible, because no allocators ever compare equal (even when you compare an
allocator to itself!)

Stateful allocators need to be a lightweight handle for some allocation
resource managed elsewhere, and two allocators compare equal if they use the
same resource. That means that you should never depend on the identity (i.e.
address) of allocator objects, only on their equivalence (as determined by
operator==).

Having looked at your code further, the test is simply completely broken. When
an allocator propagates on copy assignment the allocator gets assigned, so that
the "value" of the new allocator replaces the "value" of the old allocator.
That doesn't change the allocator's address. The object still has the same
address, it just gets a new "value". But your allocators don't have any "value"
they only care about their identity (i.e. address). This report is INVALID.


(In reply to Jonathan Wakely from comment #2)
> You know you can just not name a parameter, instead of casting it to void?

Ah yes, I see you've done that elsewhere.