Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: mallocMustSucceed( 0 ) non-portable
From: Benjamin Franksen <benjamin.franksen@bessy.de>
To: tech-talk@aps.anl.gov
Date: Tue, 31 Jan 2006 23:51:02 +0100
On Tuesday 31 January 2006 21:42, Andrew Johnson wrote:
> Michael Abbott wrote:
> >>> Of course this means that callocMustSucceed and mallocMustSucceed
> >>> can return a NULL pointer, which they currently never do.....
> >>
> >> That's the dilemma. I thought about that but I believe requesting
> >> zero-sized memory and subsequent de-referencing the return value
> >> can be considered a programming error. Otherwise, I can't see how
> >> to avoid a memory leak.
> >
> > Makes sense to me.  After all, what can you legally do with
> >     char * x = malloc(0);
> > ?
>
> I understand that position, however I really don't like it.
>
> The ?allocMustSucceed() routines were always a bit of a hack to avoid
> having to check the return value from ?alloc.  They are only called
> in dbStaticLib and the IOC startup code in places where if you run
> out of memory there's no way you're going to be able to recover and
> still bring up the IOC, so the only thing you can do is bail out.
>
> They do that by printing an error message and suspending the task,
> thus ensuring that the caller never gets a chance to continue
> processing. The task suspend is to allow a developer to do a
> back-trace on the task that failed and thus find the rogue code, in
> the event that the problem is being caused by a bug rather than a
> lack of RAM.

One could argue that the same reasoning applies to all other kinds of 
start-up code that gets executed more or less immediately after IOC 
boot, e.g. in record and device supports init and init_record routines. 
An out-of-memory situation here invariably means the IOC is overloaded 
and obviously /cannot/ run as the developer planned.

Ben

Replies:
RE: callocMustSucceed error handling model Jeff Hill
References:
mallocMustSucceed( 0 ) non-portable Till Straumann
Re: mallocMustSucceed( 0 ) non-portable Michael Abbott
Re: mallocMustSucceed( 0 ) non-portable Andrew Johnson

Navigate by Date:
Prev: Re: how to determine record type given pointer to a record Andrew Johnson
Next: RE: callocMustSucceed error handling model Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: mallocMustSucceed( 0 ) non-portable Andrew Johnson
Next: RE: callocMustSucceed error handling model Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·