Message-ID: <3EA971A1.80912C85@yahoo.com> Date: Fri, 25 Apr 2003 13:34:25 -0400 From: CBFalconer Organization: Ched Research X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en 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> <3EA91560 DOT 915334E6 AT phekda DOT freeserve DOT co DOT uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com 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 - ? > > > 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 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 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. USE worldnet address!