Message-ID: <3E74E136.2C1F3CDC@yahoo.com>
Date: Sun, 16 Mar 2003 15:40:22 -0500
From: CBFalconer <cbfalconer AT yahoo DOT com>
Organization: Ched Research
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: nmalloc revisited
References: <3E713255 DOT B2A42BDB AT yahoo DOT com> <8011-Sun16Mar2003201949+0200-eliz AT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> 
> > Date: Thu, 13 Mar 2003 20:37:25 -0500
> > From: CBFalconer <cbfalconer AT yahoo DOT com>
> >
> > I have just noticed a C99 restriction against raising signals
> > within the library.  nmalloc does raise SIGABRT in several cases,
> > where the memory arena has become fouled.  This is concentrated in
> > the routine badcallabort(), which is called from various places.
> >
> > Is this worth worrying about
> 
> I think you could simply call `abort()' instead of raising SIGABRT.
> One or two core library functions already do that.
> 
> Would that be okay?  If not, please tell why not.

No problem either way, except that it seems rather unfriendly.  In
some cases it is possible to recover from the badcallabort to some
extent, and this can be done by the user trapping the SIGABRT and
rerturning.  If it is not feasible the system presently calls
exit(EXIT_FAILURE) after the raise(SIGABRT);  Se the actual code.

-- 
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!