This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] libstdc++/20150
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