Message-ID:	<3EF0BF62.11E71044@yahoo.com>
Date:	Wed, 18 Jun 2003 15:37:06 -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> <3EECD63E DOT 19C52226 AT yahoo DOT com> <3EEE24E7 DOT E7B03AB0 AT phekda DOT freeserve DOT co DOT uk> <3EEE3821 DOT 2C04E9D4 AT yahoo DOT com> <3EEF6925 DOT 43CCBDBB AT phekda DOT freeserve DOT co DOT uk> <3EEFD834 DOT 45AD84AE AT yahoo DOT com> <2950-Wed18Jun2003064448+0300-eliz AT elta DOT co DOT il> <3EF00098 DOT 5FE616DE AT yahoo DOT com>
Reply-To:	djgpp-workers AT delorie DOT com

CBFalconer wrote:
> Eli Zaretskii wrote:
> > >
... snip ...
> >
> > version of the library code and cannot look at that yourself.  It is
> > also unreasonable to expect us to replace malloc with something that
> > breaks some of related features.  Each feature we put into DJGPP is
> > sorely needed somewhere (Mark explained in this thread why memalign
> > and friends were added: to be able to port latest versions of GCC), so
> > we cannot afford to stop their support.  We need nmalloc to be
> > compatible with memalign.
> >
... snip ...
> >
> >   http://www.ludd.luth.se/~ams/djgpp/cvs/
> >
.. snip ...
> 
> I can go get that, but what the d*evil am I looking for?  Mark E.
> brought up another herd of interfaces?  Where does it end?  I
> don't want to rebuild everything.  I have no idea how long it will
> take to implement.  Basically I am thinking that nmalloc assigns
> an overlarge piece, saws off the head and puts it in the free
> list, saws off the tail and put that in the free list, and returns
> the remainder.  This will definitely complicate nmalloc.  And I
> have doubts that it is the right approach.
> 
> And what about those other things, vmalloc, mmap, whatever?

I am looking at memalign.c and memalign.txh.  I am planning to
install it in the main nmalloc module.  It will reject all non
power of 2 alignment constants, also 0.  As malloc, it will reject
any request for INT_MAX - 65536 or over, or an alignment over
65536.  At least so far.  

How should this tie into the various hooks, i.e. should it act
just like another malloc?  Should it be non-hookable?  Should
failures act like a malloc failure?  All hook routines are called
with a pointer and a size as parameters, so there is no room to
echo back the alignment constant.  I suppose if they need a third
parameter now is the time to add it.

AFAICT the other routines mentioned call memalign, and can be
ignored.

I think somebody has their head-firmly-up if they are making gcc
depend on these non-standardisms.  It is going to become
impossible to port.

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