This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: valgrind confused by std::allocator calls to operator new(0)

From: Nathan Myers <ncm-nospam at cantrip dot org>
To: libstdc++ at gcc dot gnu dot org
Date: Tue, 22 Feb 2005 06:27:12 -0800
Subject: Re: valgrind confused by std::allocator calls to operator new(0)
References: <OF63B462D7.F58248F0-ON42256FB0.001F86A2-42256FB0.0024499E@il.ibm.com> <m37jl0ww5n.fsf@uniton.integrable-solutions.net>

On Tue, Feb 22, 2005 at 02:40:04PM +0100, Gabriel Dos Reis wrote:
> Michael Veksler <VEKSLER@il.ibm.com> writes:
> 
> | Is it possible/reasonable to change new_allocator::allocate such that
> | it returns NULL when __n ==0 ? Should I open a PR against libstdc++?
> 
> Yes, please.

No, the bug is in valgrind, because zero arguments to the allocators
are explicitly allowed.  If we choose to work around the valgrind bug, 
the workaround belongs in std::vector, not in the allocators.  (It is
a minor optimization, anyway, to avoid performing an allocation when 
copying an empty vector.)

Nathan Myers
ncm@cantrip.org

Follow-Ups:
- Re: valgrind confused by std::allocator calls to operator new(0)
  - From: Gabriel Dos Reis

References:
- valgrind confused by std::allocator calls to operator new(0)
  - From: Michael Veksler
- Re: valgrind confused by std::allocator calls to operator new(0)
  - From: Gabriel Dos Reis

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]