Mail Archives: djgpp-workers/2003/04/25/03:05:40
Charles Sandmann wrote:
>
> > 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)
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. 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.
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
- Raw text -