[v3] libstdc++/20150

[Nathan Myers]

On Wed, Feb 23, 2005 at 12:06:32AM -0600, Benjamin Kosnik wrote:
> 
> Fixups for allocator::allocate(0), tests.
> 
> tested x86/linux

> 2005-02-22  Benjamin Kosnik  <bkoz@redhat.com>
> 
> 	PR libstdc++/20150
> 	* include/ext/malloc_allocator.h (malloc_allocator::allocate):
> 	Check for zero size.
> 	* include/ext/new_allocator.h: Same.
> 	* include/ext/array_allocator.h: Same.
> 	* include/ext/bitmap_allocator.h: Same.
> 	* include/ext/mt_allocator.h: Same.	

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.  Introducing a 
new special case makes the interface more complicated for no practical 
benefit to anyone.  

If valgrind can't handle an allocator returning a valid pointer to
storage for zero bytes, that's a bug in valgrind, because it's 
explicitly permitted (formerly, required) standard behavior.

Nathan Myers
ncm@cantrip.org