Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!dkuug!freja.diku.dk!njk
From: njk@diku.dk (Niels J|rgen Kruse)
Newsgroups: comp.lang.c
Subject: Re: Dynamic Storage Allocator Pros and Cons
Message-ID: <1990Nov21.212147.20783@diku.dk>
Date: 21 Nov 90 21:21:47 GMT
References: <241@smds.UUCP>
Organization: Department Of Computer Science, University Of Copenhagen
Lines: 25

rh@smds.UUCP (Richard Harter) writes:

>Security and Error Checking:
>This is the reason for using G/R, if it matters to you.  Specifically
>the features are:
>(A)    All invalid size requests (zero, negative, too large) are trapped.
---------------------------------------------------^^^^^^^^^
Try ``getsp (2147483646,0)''.   ;-)

Another bug: The return value of malloc in GETNODES is never
checked, so if malloc returns NULL, getsp dump core quite
ungracefully.

BTW, Thanks for posting your Storage allocation package, it
makes what you have previously told about it a lot clearer.

PS: You call it a Best Fit allocator.  This is only true for
sizes smaller than 1Kb, for larger blocks the selection
strategy is LIFO.  This means that the memory utilization
achieved is quite a lot lower than that of a true Best Fit
storage allocator.

PPS: If you change the #define for BKSZ to
``( 65472 & (unsigned)-1/2 )'', the code will also work on a
Xenix286 system in large memory model.
-- 
Niels J|rgen Kruse 	DIKU Graduate 	njk@diku.dk