X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Message-ID:	<3C7FF20B.FAFE67BF@yahoo.com>
Date:	Fri, 01 Mar 2002 16:26:35 -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: Malloc/free DJGPP code
References:	<10203011554 DOT AA19213 AT clio DOT rice DOT edu>
Reply-To:	djgpp-workers AT delorie DOT com

Charles Sandmann wrote:
> 
> > > The whole guardhi block can be removed entirely without affecting
> > > anything (except the DATAOFFSET macro).  Its sole purpose is to
> > > protect against user misuse (one off addressing) clobbering the
> > > memory arena.  The guardlo has a dual purpose, guarding and
> > > alignment.  I threw in the initialization to DEADBEEF, BEEFDEAD,
> > > F00DFEED etc. just for sport and to make memory dumps obvious.
> 
> Understood.  It's a good idea for debugging.  The concern is memory
> overhead in the production version (which will go into *every*
> image built, even those well debugged).
> 
> > A further question - will raise(SIGSEGV) in the package on
> > detectable errors foul up the initialization sequence, since
> > malloc etc. appears to be called during it?
> 
> If you are going to take the time to detect errors, a message to
> stderr() explaining the error in plain terms will be much more
> valuable.  There are lots of people who would start posting
> "there's a bug in malloc" if they see the SIGSEGV.  This is
> probably a FAQ by the way...
> 
> while malloc is called in the setup - it's called after exception
> setup - and I certainly hope we don't have bugs in the startup
> to trigger it anyway.  So I don't think a raise should break
> anything.

The sort of errors I can detect up front are: free or realloc of
an already freed item (quite positively) and, in some cases, free
or realloc of an item not in the memory arena or scrambled by an
earlier out-of-range write (via the guard words).  I know I would
rather have the programs bomb right at the call than on some later
event, or never bomb but leave data scrambled.  The point of the
SIGSEGV would be that the rest of the system would provide a
traceback, while a message to stderr would not.

Another choice is to just ignore the free/realloc calls that
operate on an already freed area, letting realloc fail.  That
would mask user errors but I would consider it unclean.

-- 
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT XXXXworldnet DOT att DOT net)
   Available for consulting/temporary embedded and systems.
   (Remove "XXXX" from reply address. yahoo works unmodified)
   mailto:uce AT ftc DOT gov  (for spambots to harvest)

- Raw text -