Re: [v3] libstdc++/20150

[Benjamin Kosnik <bkoz at redhat dot com>]

> I don't agree that these are desirable semantics for allocators, or that
> this is the right fix for the reported problem.  There's no particular
> reason for std::vector<> ever to try to allocate zero bytes, so this 
> can, and should, be fixed in std::vector, as an optimization if nothing
> else.  The traditional semantics for operator new(0) is to return a 
> valid pointer different from other extant allocations. 

I think there are three points here.

1) you don't think std::allocator(0) should return 0.

2) the testcase posted yesterday about empty vectors, allocation, and valgrind

3) operator new(0) semantics.

I'm only dealing with 1, perhaps I should have made this point more clearly. 

In particular, I'm concerned with the inconsistency between various
3.4/4.0 ext allocators when *_allocator.allocate(0) is called. That
inconsistency is as follows: __pool_alloc returns 0, the others don't.

Because of this, gcc-2.95.3 to gcc-3.3.5 return 0 for
std::allocator.allocate(0). This is not the case for gcc-3.4.x, gcc-4.x.

It's my opinon that this change was largely gratuitous. The standard
seems to indicate that either is a conforming.

As such, it seems like preserving past behavior makes the most sense.

-benjamin