delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/12/08/21:01:04

Message-ID: <3DF3F576.F481AF3@yahoo.com>
Date: Sun, 08 Dec 2002 20:44:22 -0500
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: 2.04 CVS Build plan
References: <10212050502 DOT AA26867 AT clio DOT rice DOT edu>
Reply-To: djgpp-workers AT delorie DOT com

Charles Sandmann wrote:
> > Charles Sandmann wrote:
> > >
> > > > > This hasn't had any progress. I'm waiting for the original author
> > > > > (CBFalconer) (or somebody else) to correct these issues.
> > > >
> > > > What issues?  AFAICT compiling the original source with NDEBUG
> > > > results in a module ready for inclusion in the main library.  I
> > > > added the following readme to the distribution, not sure just now
> > > > if it is in the version on my site.  The nmalloc code has not been
> > > > altered.
> > >
> > > There is a big gap between the debugging routines available in CVS,
> > > plus the documentation and what the new malloc provides.  Someone
> > > needs to either write new documentation and examples for the new
> > > malloc, or change the new malloc to work with the old documentation
> > > and malloc routines.
> >
> > I don't have that documentation.  I would appreciate an e-mail
> > with little baby steps to get the appropriate documents and
> > routine specs.  I believe I have put enough in nmalloc to allow
> > virtually anything to be created in that the internal structure is
> > available, but I have deliberately NOT tried to build areas where
> > I have no prior knowledge.  I don't want to get into overall
> > systematic issues.
> 
> You need to either install a CVS client ftp://ftp.cvshome.org/pub/win32/
> or use the cvsweb interface http://www.delorie.com/bin/cvsweb.cgi/djgpp/
> See http://www.delorie.com/djgpp/cvs.html for more information.
> 
> The particular directory where malloc lives is:
>  http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/ansi/stdlib/
> (in cvs terms that will be djgpp\src\libc\ansi\stdlib)
> 
> Source and documentation modules include:
>  makefile
>  malloc.c
>  malloc.txh
>  malldbg.c
>  xmalloc.h
>  libc/malloc.h  (this is in the djgpp\include\libc directory).
> 
> Using the web interface you can download the current source for
> each of these files in a few minutes, and also see the change at
> each checkin if you are interested.
> 
> The malloc.txh file contains the documentation, which is processed to
> create files for the info reader.  The realloc problems (and many
> others) are fixed in the CVS version.  The new debug routines and
> documentation are there too.

I don't know about realloc problems, but the motivation for
writing nmalloc in the first place was the O(n) operation of
free(), causing O(n*n) operation when freeing many components.  At
the same time I minimized data movement in realloc operation.  

**** Has anyone tried it out? ****

> 
> You can also see from
> http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/ansi/stdlib/malloc.c
> The edits which have been made since the V2.03 release, the bugs fixed.
> Some of these bug fixes are not in your working release.

I have finally been able to get some sort of documentation by
extracting a section from a diff file for malloc.txh, stripping
the left columns, and passing the result through makeinfo --html
(with many errors reported, listed below as quote).

> malloc.txh:465: Unknown command `portability'.
> ./malloc.txh:1: Next reference to nonexistent node `memory'.
> ./malloc.txh:1: `malloc' has no Up field.
> ./malloc.txh:37: Next reference to nonexistent node `memory'.
> ./malloc.txh:37: `free' has no Up field.
> ./malloc.txh:68: Next reference to nonexistent node `memory'.
> ./malloc.txh:68: `realloc' has no Up field.
> ./malloc.txh:118: Next reference to nonexistent node `memory'.
> ./malloc.txh:118: `mallinfo' has no Up field.
> ./malloc.txh:223: Next reference to nonexistent node `memory'.
> ./malloc.txh:223: `malloc_verify' has no Up field.
> ./malloc.txh:270: Next reference to nonexistent node `memory'.
> ./malloc.txh:270: `malloc_debug' has no Up field.
> ./malloc.txh:357: Next reference to nonexistent node `memory'.
> ./malloc.txh:357: `mallocmap' has no Up field.
> ./malloc.txh:388: Next reference to nonexistent node `memory'.
> ./malloc.txh:388: `malloc hook functions' has no Up field.
> ./malloc.txh:68: warning: unreferenced node `realloc'.
> ./malloc.txh:118: warning: unreferenced node `mallinfo'.
> ./malloc.txh:223: warning: unreferenced node `malloc_verify'.
> ./malloc.txh:357: warning: unreferenced node `mallocmap'.
> ./malloc.txh:388: warning: unreferenced node `malloc hook functions'.

Of the routines listed, mallinfo is immediately implementable with
no changes to nmalloc.  I think the same applies to malloc_verify
and mallocmap (the latter should not need any arming via
malloc_debug).  malloc_debug takes some thought, and some things
are not clear.  For example, nmalloc already signals when it
encounters any heap corruption.  The various hooks are also
implementable, but would require small changes to nmalloc.  In
addition the documented offsets (magic number 4 etc) would be
wrong, but there is already provision to expose the right
numbers.  I suspect that documentation is also wrong for the
existing library.

AFAICT this documentation does not appear anywhere on my system.

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