X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10203011554.AA19213@clio.rice.edu>
Subject: Re: Malloc/free DJGPP code
To: djgpp-workers AT delorie DOT com
Date: Fri, 1 Mar 2002 09:54:55 -0600 (CST)
In-Reply-To: <3C7F3AFA.E44B5AFB@yahoo.com> from "CBFalconer" at Mar 01, 2002 03:25:30 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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

As far as other comments - I don't currently have the time to do a
detailed crtical review (busy at work and at home).  But I think
several people need to do such a review on such a critical piece
of code.  If I remember correctly, it took about a year after DJ's
re-write to get enough testing, comments before the current version
was put in use.  Be patient, it may take several weeks or months.

Sometimes it's hard to find time to review 10 line changes :-(