From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10304250425.AA17241@clio.rice.edu>
Subject: Re: nmalloc revisited
To: djgpp-workers AT delorie DOT com
Date: Thu, 24 Apr 2003 23:25:36 -0500 (CDT)
In-Reply-To: <3EA85BD0.870227C4@yahoo.com> from "CBFalconer" at Apr 24, 2003 05:49:04 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

> Keeping the files separate lets me deal with one thing at a time. 
> If it all has to be visible through stdlib then stdlib can include
> them, under suitable conditionals.  Obviously the std=C99 or ansi
> options will exclude them.

Maybe this makes sense while you are testing, but not in the
final release.  Today, right now - mallinfo structure and the 
*__libc_malloc_hook type calls are defined in stdlib.h.  Why
remove them and put them in a separate file (which will slow
each and every compile - everything includes stdlib.h) - when
they are already there, and in the form required for standard
usage?

Why not just download the v2.04 alpha and edit stdlib.h as 
needed, then submit the patch?

So in other words, I'd strongly prefer anything which is standard 
with other systems NOT to be in separate file if at all possible.

New, non-standard stuff could be in a different header to avoid
namespace pollution if desired (at least my 2 cents)