This is the mail archive of the gcc-prs@gcc.gnu.org mailing list for the GCC 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: libstdc++/6712: __default_alloc_template erroneously calls realloc


The following reply was made to PR libstdc++/6712; it has been noted by GNATS.

From: Phil Edwards <phil@jaj.com>
To: brd@paradise.net.nz
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/6712: __default_alloc_template erroneously calls realloc
Date: Fri, 31 May 2002 21:40:01 -0400

 On Sat, May 18, 2002 at 06:16:34AM -0000, brd@paradise.net.nz wrote:
 > >Description:
 > In bits/stl_alloc.h (CVS rev 1.19)
 > 
 > __default_alloc_template<threads, inst>::reallocate
 > 
 > calls "realloc". "realloc" is of course part of the C malloc/free/realloc
 > system, whereas the rest of the class uses the mem_interface system.
 
 Crumbs.  I wonder how I missed that.
 
 > On systems where operator new doesn't directly call malloc, havoc ensues
 > quickly...
 
 Well, we provide operator new, and it always uses malloc.  But of course the
 users can define their own ::operator new which must be used.
 
 *looks at stl_alloc.h again*
 
 Ah, that's why I missed this.  ISO allocators aren't required to provide
 a reallocate() function, and the new_alloc class in use doesn't.  I'll change
 this PR to low priority.
 
 *looks at the rest of the library*
 
 Nothing ever takes advantage of a reallocate function.  Hmmmm.
 
 
 The easiest "fix" would be to just rip out all the reallocation routines
 that SGI had in their code.  Unused, nonstandard, and (as you've just
 pointed out) potentially fatal.
 
 Really, though, I'd like to make reallocation work, and then make parts of
 the rest of the library take advantage of it of possible.  I can think of an
 easy way to write new_alloc::reallocate, but it would suck.  Must think more.
 
 
 > On systems where realloc is not implemented at all, the library simply
 > cannot be used.
 
 If realloc isn't implemented, then their C library is noncompliant, and they
 will have bigger problems.  Since we do not provide a C library, we must assume
 that the one already in place has basic functionality.
 
 
 > >Fix:
 > Simple fix is to remove the whole if clause that contains the call to realloc.
 
 Can't really do that; the memory pool is only set up to handle requests
 of up to a certain size, with larger requests being fed directly on to
 whatever underlying mem_interface is in use.  If reallocate receives a
 too-large request (the if clause), then it can't handle it, and must feed
 it on to something else.  And I suspect that this happens quite a bit.
 
 
 Phil
 
 -- 
 If ye love wealth greater than liberty, the tranquility of servitude greater
 than the animating contest for freedom, go home and leave us in peace.  We seek
 not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
 and may posterity forget that ye were our countrymen.            - Samuel Adams


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