Mail Archives: djgpp-workers/2003/04/25/09:46:27
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/ ]
- Raw text -