This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: stl_alloc.h: malloc_alloc out of memory handling abort()s instead
- To: mharrold at cas dot org
- Subject: Re: stl_alloc.h: malloc_alloc out of memory handling abort()s instead
- From: "Martin v. Loewis" <martin at mira dot isdn dot cs dot tu-berlin dot de>
- Date: Mon, 9 Aug 1999 08:40:24 +0200
- CC: kip at lyris dot com, doko at cs dot tu-berlin dot de, gcc-bugs at gcc dot gnu dot org, inaky at peloncho dot fis dot ucm dot es, 42622-forwarded at bugs dot debian dot org
- References: <199908090302.XAA23192@cas.org>
> Please correct me if I am wrong, I'm trying to remember back quite a way.
> I believe this is because the exception mechanism needs to allocate memory
> in order to throw an exception the way gcc handles exceptions. Since it
> is already out of memory, trying to allocate more memory probably isn't
> a good idea.
>
> I seem to remember some mail in the past regarding this situation.
What you remember might have been a slightly different situation:
Whether ::operator new would properly throw an exception or not. There
was indeed the problem whether it could throw, and I believe with gcc
2.95, it can.
Section 20.4.1 clearly states that the default allocator must throw
bad_alloc. The #if 0 around BAD_ALLOC appears in the originial sources
of SGI STL 3.11, most likely because not all compilers have a
conforming <new>. In STL 3.2, this is a configurable option.
Regards,
Martin