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: Till Straumann <strauman@slac.stanford.edu>
To: Eric Norum <norume@aps.anl.gov>
Cc: EPICS Tech-Talk <tech-talk@aps.anl.gov>, Sheng Peng <pengs@slac.stanford.edu>
Date: Mon, 30 Jan 2006 18:50:02 -0800
Eric Norum wrote:
Should callocMustSucceed accept a 0 count, too?

Yes.


 e.g. replace
if(mem==0) {
with
         if(mem==0 && size!=0 && count!= 0) {

yep



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.

Till


On Jan 30, 2006, at 5:58 PM, Till Straumann wrote:


Sheng Peng recently discovered that

callocMustSucceed(0, x)

(a request for zero amount of memory)
succeeds on linux but fails on RTEMS.

(This is because according to the ISO C and IEEE 1003.1 standard
(http://www.opengroup.org/onlinepubs/009695399/functions/malloc.html)
the allocator may either return NULL [rtems] or a unique
pointer that is acceptable to free() [linux] in the case
of a zero 'size' argument)

IMO, the EPICS implementation needs to be fixed to
give consistent behavior and the API should define
whether it is legal to request zero memory (with
the side-effect of callocMustSucceed() returning
a bogus or NULL pointer which probably is against
its purpose) or not (with the possible side-effect
of breaking code).

My suggestion would be replacing the

if (mem==0)

tests by

if (mem==0 && size != 0)

thus legalizing mallocMustSucceed(0) on all platforms.

-- Till


--


Eric Norum <norume@aps.anl.gov <mailto:norume@aps.anl.gov>>

Advanced Photon Source

Argonne National Laboratory

(630) 252-4793







Replies:
Re: mallocMustSucceed( 0 ) non-portable Michael Abbott
References:
mallocMustSucceed( 0 ) non-portable Till Straumann
Re: mallocMustSucceed( 0 ) non-portable Eric Norum

Navigate by Date:
Prev: Re: enhanced seq record Benjamin Franksen
Next: Re: mallocMustSucceed( 0 ) non-portable Michael Abbott
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 Eric Norum
Next: Re: mallocMustSucceed( 0 ) non-portable Michael Abbott
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 ·