This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/6712: __default_alloc_template erroneously calls realloc
- From: Phil Edwards <phil at jaj dot com>
- To: pme at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 1 Jun 2002 01:46:02 -0000
- Subject: Re: libstdc++/6712: __default_alloc_template erroneously calls realloc
- Reply-to: Phil Edwards <phil at jaj dot com>
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