X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Message-ID: <3C7F3AFA.E44B5AFB@yahoo.com>
Date: Fri, 01 Mar 2002 03:25:30 -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: <10202281548 DOT AA27673 AT clio DOT rice DOT edu> <3C7E6500 DOT AFE5FEF7 AT yahoo DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

CBFalconer wrote:
> 
> Charles Sandmann wrote:
> >
> > One quick comment:  The block overhead moves from 8 bytes per malloc to
> > 32 bytes per malloc.  For lots of small allocations this could be a
> > problem on small memory machines.  I'd prefer to remove the guardhi 8 bytes
> > to reduce the overhead to 24 bytes per block, or to move all of the
> > information before the block and plan to align on 16-byte boundaries.
> 
> 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.
> 
> I am working on the realloc mechanism now, and it looks as if it
> is going to be able to avoid most of the copying in the most
> common user sequences, such as while more input double (or
> otherwise extend) the buffer size.
> 
> When realloc is done I will be able to run some comparisons
> against the old version with the software that exposed the free
> problem in the first place.  That will also check compatibility
> with the rest of the run-time.
> 
> Something that might be considered is a standard trap when
> inconsistent memory structure is detected, to abort the user
> program with suitable info as early as possible.  None of this
> affects the basic design.
> 
> What do you think about the debuggery system linkage, in my 4:50
> am today message?

Not a sound from anyone on all this.  Is this of total disinterest
to everybody?

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?

-- 
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)