Path: utzoo!attcan!uunet!tank!ncar!ames!pacbell!att!whuts!homxb!hropus!ki4pv!cdis-1!tanner From: tanner@cdis-1.uucp (Dr. T. Andrews) Newsgroups: comp.lang.c Subject: Re: memory allocation Message-ID: <7105@cdis-1.uucp> Date: 19 Sep 88 13:57:22 GMT References: <1262@micomvax.UUCP> <733@proxftl.UUCP> <33184@cca.CCA.COM> <33422@cca.CCA.COM> Distribution: comp.lang.c,comp.os.misc Organization: CompuData Inc., DeLand Lines: 28 In article <33422@cca.CCA.COM>, g-rh@cca.CCA.COM (Richard Harter) writes: ) One point which I feel strongly about is that most allocators use the ) blocks (free and allocated) to hold control information. I think that ) this is a mistake. I put all control information in structures in a ) separate node space. Unless you hard-code a limit ofallocated blocks, you have to allocate the separate node space from the same heap, leaving the control information somewhat vulnerable (OK, so now it's arry[-3] instead of [-1] that trashes you). I stuck the control information in the blocks, and can still check my free() calls. Two things assist in this. On free() calls, I trace the list until I find the block to be freed. If it isn't a valid block, it isn't free()d. As the block is being freed, I coalesce the adjacent free block(s). At most 3 blocks may be collected (the freed block and the ones immediately above and below). It seems much better to do this work wen the block is freed (if ever) rather than to perform trash-mashing at malloc() time. Secondly: the third control word in the block (after a pointer to the next block and the size of the current block) is the "XOR" of the two other control words. This gives a good indication if arry[-1] has been tampered. -- ...!bikini.cis.ufl.edu!ki4pv!cdis-1!tanner ...!bpa!cdin-1!cdis-1!tanner or... {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!cdis-1!tanner