actual size of a malloc()'d block
Brett Galloway
brett at wjvax.UUCP
Thu Feb 4 07:30:54 AEST 1988
In article <1988Feb1.182545.12952 at jarvis.csri.toronto.edu> flaps at csri.toronto.edu (Alan J Rosenthal) writes:
>
>In article <1209 at wjvax.UUCP> I wrote:
>[ on: having a function to return the amount of size in a malloc'd block ]
>>All implementations of malloc() will give you *at least* the amount of
>>room you asked for; many will give you more. I have several
>>applications where I could make more efficient use of space if I knew
>>how much space malloc() actually gave me. ...
>
>I don't see why this would save you time.
>
>If the value you call realloc() with is greater than the malloc() value
>but less than the amount actually allocated, obviously nothing will
>happen ... [example form SUN OS 3.3]
It does save you the call to realloc() ... Actually, cases where one
will malloc() and then realloc() repeatedly are not the best example
why a malloc() that returned the actual size allocated would be useful
(despite the fact that that's the example I gave).
A better example is a related case. I have an application where I
am accumulating an indefinite number of items. One way to solve this
would be to use malloc() ... realloc() ... realloc() as required.
However, as the size grows, performance gets worse and worse. An
opposite extreme solution is to allocate single items on a linked
list. But that incurs substantial overhead. My middle solution was
to allocate nodes on a linked list that stored some quantity of items
per node. It would be more efficient if I could know when more items
would fit in a node than I asked for.
--
-------------
Brett D. Galloway
{ac6,calma,cerebus,isi,isieng,pyramid,tymix}!wjvax!brett
More information about the Comp.lang.c
mailing list