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)


On Tue, Feb 22, 2005 at 10:53:31AM +0100, Paolo Carlini wrote:
> Michael Veksler wrote:
> 
> >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.

This may be out of context...  The standard defines that allocators
(and operator new) may be asked for zero bytes.  They must return an
address different from any other address that they have returned that 
haven't since been released.  (That disallows returning 0.)  Most 
implementations treat a call to operator new(0) identically to operator 
new(1).

I agree that there's no reason for the library ever to call it with a 
zero argument.

Nathan Myers
ncm@cantrip.org


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