delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2003/06/15/16:29:09

Message-ID: <3EECD63E.19C52226@yahoo.com>
Date: Sun, 15 Jun 2003 16:25:34 -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 integration issues: memalign, names
References: <3EECBA0F DOT 9D6D4B30 AT phekda DOT freeserve DOT co DOT uk>
Reply-To: djgpp-workers AT delorie DOT com

Richard Dawe wrote:
> 
> I've just started looking at integrating nmalloc. CBFalconer: I have
> a couple of problems:
> 
> * memalign relies on <libc/malloc.h>. As I understand it, nmalloc
> uses a different memory-block format than the current implementation.
> 
> memalign is new in 2.04. CBFalconer, please please please check out
> CVS! This needs fixing, before I can integrate the code. You will
> need a CVS checkout anyway for later maintenance.

I have a whole bunch of excuses: I have never used CVS, I am
getting short of disk space, I am a crusty old fogie, I am running
an ancient 486/80.  I don't understand "memalign", where does that
id come from?  In nmalloc alignment is governed by ALIGN define.
> 
> What should we do with the new block format? Put it in <libc/malloc.h>?
> Or should <libc/malloc.h> become an empty header? (It seems to me like
> the block format should go in <libc/malloc.h>.)

If I understand you correctly, you are referring to the internal
structure of allocated blocks.  That is what sysquery is for - it
exports the details, so things can dynamically adapt to any
changes in nmalloc.  Outside of debug version, the only external
things nmalloc needs is the prototypes for malloc, free, realloc,
and sbrk.  The usage in malldbg and the macros therein illustate
accessing everything.

> 
> * I don't like the names of the hook things in sysquery.h. malloc_HK,
> etc. I think should be prefixed with two underscores, since this
> stuff is library-internal. I think m_* and M_* should be expanded to
> __malloc_* and __MALLOC_*.
> 
> * Please tell me how you see the files mapping into CVS. I have my
> ideas, but I'd like to know what you think.
> 
> My current plan is not to remove any files, just add the new ones and
> change the Makefile. This plan does not work so well with texinfo
> files. Perhaps I could rename .txh -> .txo, so that they're still
> present in CVS. I guess this doesn't add anything, so maybe it's
> better if I just add nmalloc.txh and remove the old files.

I have no idea on the CVS.  I am perfectly amenable to changing
such names; so far they are never used outside of the nmalloc
package, so now is the time to change them.  I envisioned that the
library make would refer to nmalloc.c and malldbg.c and their
dependancies, possibly also nmalloc.txh (or whatever it gets
renamed to).  I also originally envisioned stdlib.h just
#including malldbg.h and sysquery.h in the appropriate places with
the appropriate guards.  That way there is only one place to
modify.

The existing nmalloc makefile is a mess, but suffices for
independent modification and testing.  It is obviously not going
to be used in creating the library.

Another area that may well need standardization is my convention
for #include guards.

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019