Mail Archives: djgpp-workers/2003/04/25/14:22:05
Richard Dawe wrote:
> 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 would add in the empty line "DJGPP 2.03 has it" :-) (at least
for our purposes). In a few months that might change to 2.04.
>
> 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?
As an example, with nmalloc specifically in mind, I have
conditionals in there that allow for more rigorous monitoring of
arena health with guards. They have a cost, in that the overhead
per allocation goes up from 16 to 24 bytes. The sysquery
mechanism specifically exports the results, so that all other
software should remain in sync with no further effort. That
mechanism could be made even more rigid, by checking for
overwrites beyond the original request size, rather than (as at
present) beyond the rounded up request size.
A further future possibility: the system collects the lastsbrk
space, so it would be perfectly possible to add a condition <if
larger than XXX return YYY to the system>. If this happens the
debuggery should be able to hook that occurence. That would, at
present, only involve adding an identifier to the enumerated
xxx_HK cases, and some minor coding. The enumeration is done only
in sysquery.h.
A future enhancement might be a flag of some sort. Set it, and
all manipulations are tagged. Reset it at some point. Later on
examine only the tagged items, or the untagged items.
And then there are all the things that nobody has conceived of
yet. :-) I really think nmalloc achieves a new high in
debugability combined with safety and future flexibility. Since it
depends on nothing more than sbrk (and GCC for the debug macros),
it should export to the Linux/Unix world with ease.
The user need never know that these files are separate, if they
are automatically included in stdlib.h. I doubt very much that
the time to open and close them seriously affects compilation time
for anything non-trivial. I believe gcc already has a mechanism
for saving guard conditions and avoiding even that. The files are
small, so reading time is not as important as open/close.
BTW, your proposed rules make everything to do with hook functions
totally non-standard.
What the purpose of the level parameter in mallocmap originally
was escapes me. I have specified a purpose in the hacked .txh I
supplied, but it may well diverge. I would appreciate getting
back a cleaned up version ASAP, as it makes a better working
document than the original, at least for my purposes. Maybe it
should be split in two, the unchanging part dealing with malloc,
free, realloc alone. If so I suggest the new part be named
malldbg.txh.
I didn't know what I was getting into when I tackled this :-) My
oldest zip snapshot is dated Feb 2002! It gives me great respect
for how the other arcane overall system aspects are getting
handled and meshed.
--
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 -