[ILUG] Re: thoughts on malloc...

[kevin lyda]

On Wed, Mar 27, 2002 at 10:52:40AM +0000, John P. Looney wrote:
>  I may be wrong, but I don't think there is just a table, as such. when
> you do;

uh, i think i said exactly that in the message you replied to.
regardless, it's implementation dependant and you can't depend how
it's done.

>  As unix people, we should really know exactly how this works. Anyone care
> to explain ?

no, you shouldn't care how it works.  it's libc dependant.  which means
that unless you're implementing libc, leave it alone.

On Wed, Mar 27, 2002 at 10:35:10AM +0000, Nick Murtagh wrote:
> But would the "reserve" call actually allocate the memory? If not, you'll
> still have to check the return from every malloc, and do all the messy
> stuff with free!

yes, it would reserve memory.  and so yes, there's the chance for a
memory leak.  the unreserve call will unallocate any memory not used
from the matching reserve call.  so if you malloc_reserve 1024 bytes
and then only use 100 bytes, the matching unreserve call would remove
the reserveation for the remaining 924 bytes.

btw, in reading the info pages on glibc it might be possible to mimic
this functionality with either malloc hooks, free hooks or with mallopt.
all of these are glibc specific however.  it's too bad libc is so cast
in stone - be nice if there was a c equiv to cpan.

kevin

-- 
kevin at suberic.net          buffy: come on, can't you put your foot down?!
fork()'ed on 37058400      giles: it *is* down.
meatspace place: orbit     buffy: one of these days you're going to have to
http://suberic.net/~kevin         get a grown up car.  --inca mummy girl