From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10303180513.AA17204@clio.rice.edu>
Subject: Re: nmalloc revisited
To: djgpp-workers AT delorie DOT com
Date: Mon, 17 Mar 2003 23:13:33 -0600 (CST)
In-Reply-To: <3E762E23.A2F38193@yahoo.com> from "CBFalconer" at Mar 17, 2003 03:20:51 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

> The standard interface is in the ISO standards document.  This is
> the one thing that has to be met.  Has anyone run the existing
> test mechanism?  This is what tnmalloc produces, with no
> undocumented interface, and getting the magic values dynamically
> from sysquery:

I've run it, but as I've said before, there is no documentation for
the interface you have provided, and out of the box it provides 
less functionality than what is currently provided in a documented
form.  When I say documentation, I mean final form user documentation
as is provided for all other routines in the library.

> I put this all out there, complete with the tests, so people could
> evaluate it and complain if it was lacking in some manner, WITH
> RESPECT TO ISO standards. I have heard not one word about this
> fundamental compliance (or lack) from anyone.  Martin S seems to
> have quietly mounted it in his system, and apparently had no
> trouble except with these non-standard interfaces. 

I tested it in some lightweight applications and saw no problems.
It looks sound to me - but I didn't do a complete code review or
stress it in extreme cases.  In particular, 2.001 GB requests and
other such nonsense.  In an earlier version I checked you did not
have all the checks for abnormal cases that the CVS version has
added over the last 5 years.  Maybe fixed now, been busy.

> I find DJGPP to be a fundamentally good and reasonably efficient
> system.  I saw a glaring flaw, and rather than bitch incessantly,
> I fixed it with, I believe, sound and clear code.  Apparently very
> few care to even look at the result.

I appreciate this, but I haven't had the time to try to fill the
gap between the provided code and a full package.  I'm already in
deep time trouble over updated DXE, which was an earlier commitment.

I go on site to work for a client in Europe for 4 months in May, so
if I don't get DXE done before May, I'll be pretty much completely
unavailable until September.  I'm hoping V2.04 will be out before
then ;-)

> I am still willing to take a shot at a near compatible debug
> interface, as I proposed with a previous message (see the
> malldbg.h header).

It needs to be identical compatible, or it needs updated info 
documentation describing what's different.  It also needs to compile
into the library environment and work with the test programs, or
they also need to be modified.