From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10304211942.AA12379@clio.rice.edu>
Subject: Re: nmalloc revisited
To: djgpp-workers AT delorie DOT com
Date: Mon, 21 Apr 2003 14:42:16 -0500 (CDT)
In-Reply-To: <3EA41578.9E69308C@yahoo.com> from "CBFalconer" at Apr 21, 2003 11:59:53 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

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

Please, please, please get a copy of the CVS version of malloc
and take a look at it.  The first executable section in malloc()
is:

  /* Refuse ridiculously large requests right away.  Anything beyond
     2GB will be treated by sbrk as a negative request, i.e. as a
     request to _decrease_ the heap size.  */
  if (size > 0x7fffffffU - 0x10000U) /* sbrk rounds up to 64KB */
  {
    if (__libc_malloc_fail_hook)
      __libc_malloc_fail_hook(size);
    return 0;
  }

sbrk() takes a signed integer - so you must make sure you don't
pass it anything too big.  If someone passes a request to malloc
for something huge, and you pass it to sbrk() - problems.  It 
appears to succeed, but instead has just decreased the memory
available (bad corruption).

There were also some other fixes since V2.03 - looking at the CVS
log would help figure out what those are and to make sure they
are in nmalloc:

http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/ansi/stdlib/malloc.c

This gives a history of the changes - there have been 7 changes since
V2.03.

> What about my new method of installing hooks?  

I will defer to Eli and other developers on that call.  I have no
opinion either way.  But we must be compatible with V2.03, 
provide the needed V2.04 functionality (assumed to be CVS type
features) and the documentation matches the code.