From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10304200441.AA22048@clio.rice.edu>
Subject: Re: nmalloc revisited
To: djgpp-workers AT delorie DOT com
Date: Sat, 19 Apr 2003 23:41:43 -0500 (CDT)
In-Reply-To: <3EA1C57D.E3861F84@yahoo.com> from "CBFalconer" at Apr 19, 2003 05:54:05 PM
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

Okay, here's a listing of the ZIP file:

tnmalloc.c          nmalloc.c           nmalloc.h           nmalloc.lst         
cokusmt.c           cokusmt.h           fakesbrk.h          sysquery.h          
makefile            xref.exe            evilalgo.c          readme.txt          
gaussran.c          hookmem.h           malldbg.c           malldbg.h           
tmalldbg.c          

There is no "info" documentation in this package.  Who is going to
write it?  My suggestion is that if you make the new package completely
compatible with the current code/documentation - then no documentation
needs to be written/modified.  If you want to change the way the world
works - then you have to re-write the documentation, build and test
files too.

> AFAIK the present libc doesn't include the hooks, and you have to
> use a different library.  

The current library provides a way for the user to provide hooks.
You don't have to use any different library, just whatever hooks
you might want to call.

If you plan that getting additional debug information should require
a separately compiled module/library - then this different than the
current libc (a problem).  If this is the plan, then someone has to
modify the build system to create it, and you will need to write the
documentation to describe the additional library, how to use it,
the make files to create it, etc.  You will also need to re-write
the docs to remove all the references to the current hooks.  All 
DJGPP documentation is provided in info format.

> As I pointed out before, I did it this way to avoid changing the
> nmalloc source and test that everything is satisfactory.  

You are willing to create a lot of additional work (which no one
seems to want to do) to avoid changing a few lines in the source?

> It is not advisable to have all that hook code in the routine library
> anyway, as it simply adds unused overhead.  Look at the readme.txt
> in the zip file.

If I posted all 1651 bytes of it to the list would you be convinced
that we read it?  Is this your idea of acceptable documentation, compared
with the 15961 bytes currently describing the current malloc library
and debugging setup (in the proper format)?  You have been critical
of the DJGPP documentation in the past.  If we left the entire library's
documentation in this state, you certainly wouldn't be satisfied.

The hook code is negligible overhead.

> As I said before, I don't like having the hooks exposed as common
> global variables, and would much rather install/remove them with a
> single function.  But if people insist, I put them in and they can
> be used.  I would much rather take them out.

I personally don't care one way or the other how it's done.  But I do
believe we need a complete package of code, build package and 
info documentation - all consistent.

> I highly suspect there is a lot of misunderstanding going on. 
> Naturally, I think I have it all straight :-).
> 
> As distributed in nmalloc.zip, you can do several things to try it
> all out without disturbing libc:
> 
>   Normal use    -  do nothing.
>   Try nmalloc   -  link malloc.o before searching the library
>                    This can be replaced by replacing the 
>                    malloc.o module in the library.
>   Try debuggery -  link both malldbg.o and hookmem.o before
>                    searching the library.  Again, there is no
>                    reason those could not be placed in the 
>                    library proper, except that if all is
>                    suitable I will combine them into a 
>                    single module.
> 
> In everything except the normal use case, malloc, free, and
> realloc are resolved before searching libc, so that the original
> code is never loaded.

I understand this, but this doesn't match the current documentation.
It would be wonderful for a contrib package, but it doesn't match
what's in the documentation and build package - and thus is hard
to put in the main distribution.