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: Paolo Carlini <pcarlini at suse dot de>
To: Michael Veksler <VEKSLER at il dot ibm dot com>
Cc: libstdc++ at gcc dot gnu dot org
Date: Tue, 22 Feb 2005 10:53:31 +0100
Subject: Re: valgrind confused by std::allocator calls to operator new(0)
References: <OF63B462D7.F58248F0-ON42256FB0.001F86A2-42256FB0.0024499E@il.ibm.com>

Michael Veksler wrote:

It may be viewed as a low priority regression. In gcc-3.2 std::allocator does not behave this way.

Well, it depends on the allocator you select at library build time: for instance, the equivalent allocator in mainline (pool) or the default (mt) also don't call new(0).

Is it possible/reasonable to change new_allocator::allocate such that
it returns NULL when __n ==0 ? Should I open a PR against libstdc++?

I agree that calling new(0) is dumb and we should simply standardize on the behavior of pool and mt: it's just a matter of adding a conditional to new_allocator, seems safe for 3.4.4 too. Please file a PR, thanks.

Paolo.

Follow-Ups:
- Re: valgrind confused by std::allocator calls to operator new(0)
  - From: Nathan Myers
- Re: valgrind confused by std::allocator calls to operator new(0)
  - From: Benjamin Kosnik

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

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