From 611091763274005498 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,81cfa62a82013905 X-Google-Attributes: gidf78e5,public From: "Paul D. DeRocco" Subject: Re: bad_alloc Date: 1997/10/07 Message-ID: <3439DC66.F263FDB0@ix.netcom.crud.com>#1/1 X-Deja-AN: 278995701 References: <3433222F.5644@CAM.ORG> X-Original-Date: Tue, 07 Oct 1997 02:53:26 -0400 Organization: Adult Children of Liberals X-Netcom-Date: Tue Oct 07 1:55:58 AM CDT 1997 X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANDndfOEDnX0m9pzZAQH4wgF9FdAicPqdWdTIdnke5QCIdgbKtOtm38kD CbZfHzXkvLPZMDz/sqAqD1yArt0fC/sx =DlG/ Newsgroups: comp.std.c++ John D. Hickin wrote: > > The following snippet of code produced a stack overflow. Is this an > artifact of the standard or of the implementation? > > try { while ( new char[42] ); } > catch( const std::bad_alloc& ) { } > > Evidently we require some memory to build a bad_alloc. The standard > says that bad_alloc() won't throw. Can this be insured? The implementation. Looks like a bug to me. The only implementation I've used extensively (Borland) reserves 128 bytes for creating exceptions in, so can usually throw bad_alloc even when memory is exhausted. My guess is that this particular implementation tried to call "new std::bad_alloc", and hence went into infinite recursion. -- Ciao, Paul (Please remove the extra "crud" from the return address, which has been altered to foil junk mail senders.) --- [ comp.std.c++ is moderated. To submit articles: try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ] [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ] [ Comments? mailto:std-c++-request@ncar.ucar.edu ]