Message-ID: <3EA41578.9E69308C@yahoo.com>
Date: Mon, 21 Apr 2003 11:59:53 -0400
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: nmalloc revisited
References: <10304211406 DOT AA25239 AT clio DOT rice DOT edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Charles Sandmann wrote:
> 
> > You mean you are ready to incorporate it?  This was intended to
> > allow others to thrash it, and expose any crawling creatures with
> > more than four legs or less than one.
> 
> Martin Stromberg ran it as his default malloc in his CVS tree
> for quite some time.
> 
> The only way to get a more extensive test is to put it in an
> alpha test of the entire build suite.  So in a word, yes - if
> we could get the issues resolved I'd want to incorporate it
> (which is why I'm so bitchy about the compatibilty/docs).
> 
> I'd still like to make sure all the tests added since V2.03
> (for things like fluffy 2GB+ mallocs) are fixed.

Ok, this is a new objective, AFAIAmC.  What is fluffy 2GB+
malloc?  If sbrk performs, I expect nmalloc will, but IHBWB.

What about my new method of installing hooks?  I would dearly love
to discard the old, which isn't publicized in 2.03, and so
shouldn't harm much.  The debug_level could also do with a change
- I would prefer to see individual features enabled by individual
bits, so the user can pick and choose:

Bit
  0:  Nothing.  Even installing hooks is prevented
  1:  External hook installation allowed.
  2:  Malloc_verify enabled, messages only if anomalies 
  4:  Automatic verify on all malloc/realloc calls, message only
  8:  Verify does immediate abort.
 16:  Reports free(NULL)

out of which we can build several published constants as arguments
for malloc_debug.  Something like:

tyoedef enum (DBG_OFF = 0, DBG_HOOKS = 1, DBG_VERIFY = 2, 
              DBG_AUTOVERIFY = 6, DBG_CATCH = 14,
              DBG_FREENULL = 16) DBGKIND;

and free the code from dependance on arbitrary magic numbers.  Now
if that bit assignment isn't viable it can easily be changed.

DBGKIND malloc_debug(DBGKIND level);


possible user level code:

   if (!(newlevel = malloc_debug(DBG_CATCH, NULL)) {
      fprintf(stderr,
        "Must first reset to DBG_OFF or remove existing hooks");
   }
   else current_lvl = new_lvl;

or

   current_lvl = malloc_debug(DBG_AUTOVERIFY, logfile);
   /* code under suspicion for fouling its nest */
   current_lvl = malloc_debug(current_lvl, logfile);

to isolate the slowdowns to the area under suspicion.  I don't
know of any system that provides such convenient features.

(taking pity on the future maintainer).  The earlier such changes
are made the easier it all becomes.

-- 
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!