Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3EA91560.915334E6@phekda.freeserve.co.uk>
Date: Fri, 25 Apr 2003 12:00:48 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: nmalloc revisited
References: <10304250425 DOT AA17241 AT clio DOT rice DOT edu> <3EA8D56E DOT A34EDFBA AT yahoo DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

CBFalconer wrote:
> 
> Charles Sandmann wrote:
[snip]
> > 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)
> 
> I don't especially mind, but are we using the same definition of
> 'standard'?  To me, anything that isn't in the C99 specification
> is non-standard.

I see a hierarchy of standardness from official through de facto standardness:

Very standard |   C99 has it
              |   POSIX has it
De facto      |   Several Unices/Linuces have it
standard      |
              |   A couple of Unices/Linuces have it
Not standard  |   A Unix/Linux has it
             \+/

I think the malloc debug interfaces are somewhere between a de facto standard
and not standard. So IMHO I'd say the de facto part is more important and they
can be considered as a "standard". So we should define them in the same
places as the platform we're being compatible with, i.e. the same header.

The non-standard interfaces can go wherever - <libc/malldbg.h>?

> Once the conditions for inclusion in stdlib.h
> are resolved, it is obviously possible to simply paste the other
> headers in.  However separation has significant advantages IMO,
> i.e. no namespace pollution unless the user specifically wants the
> features.  This also means the features can be used in software
> compiled with -W -Wall -ansi -pedantic, by simply specifying the
> extra include files.  Of course this feature can also be handled
> by making the extra header files available, rather than solely in
> stdlib.h, but that runs into the possibility of getting out of
> sync.

If the interfaces in <stdlib.h> are a de facto standard that we're complying
with, how are they going to get out of sync?

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]