This is the mail archive of the gcc-bugs@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]

Re: Minor exception bug with unexpected


On Fri, Mar 20, 1998 at 06:12:39AM +0100, Alexandre Oliva wrote:
> ak  writes:
> 
> > On Thu, Mar 19, 1998 at 04:24:35PM +0100, Alexandre Oliva wrote:
> >> ak  writes:
> >> 
> >> > The appended example dumps core in __check_eh_spec. Although that
> >> > is legal in CD2 [except.special says "The unexpected() function shall 
> >> > not return"], it is still not very nice to the user. The patch 
> >> > makes unexpected() call terminate() in this case.
> >> 
> >> I'd rather call abort() instead of terminate().  Calling terminate()
> >> might cause yet more unexpected results (unavoidable pun, sorry :-)
> 
> > What unexpected results should it cause? abort is a bit too radical
> > for my tastes.
> 
> What if terminate() is replaced by the programmer too, and it returns
> instead of calling terminating?  Instead of adding a call to
> terminate() then a call to abort(), I'd rather call abort() directly,
> because terminate() is *not* expected to be called after unexpected().
> Since we're moving into grey area (undefined behavior), I'd rather
> keep things simple, and abort()ing seems better to me, even for
> debugging purposes.

You're right. I didn't notice that __default_terminate() calls abort()
instead of a cleaner exit(0). My prefered behaviour would be
	
	/* Or the equivalent on the non-unix gcc target, otherwise nothing */
	write(1, "unexpected exception\n", 21);
	exit(1); 

abort() usually causes a core dump which I see as overkill here.

Comments?


-Andi



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