Re: [v3] libstdc++/20150

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Wed, Feb 23, 2005 at 01:01:28PM -0600, Benjamin Kosnik wrote:
> 
> > 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.

If std::allocator<T>::allocate(0) doesn't match operator new(0), that's
another bug.  

If the allocator doesn't return zero in 3.4, that's a bug fixed, not 
something to discard lightly these days.

It sounds as if fixing __pool_alloc never to return NULL suffices.  
std::vector<>'s copy ctor asking for zero bytes isn't, strictly 
speaking, a bug, but if a minor optimization there also helps to work 
around a valgrind bug, that's hard to object to.  Has anybody filed 
the bug against valgrind?

Nathan Myers
ncm@cantrip.org