To find out the names of open files in a process

[Brett Galloway]

>In article <1427 at mips.mips.COM> hansen at mips.COM (Craig Hansen) writes:
>>In article <904 at thorin.cs.unc.edu>, gallmeis at wasp.cs.unc.edu (Bill Gallmeister) writes:
>>> this kind of reminds me of someone who asked how to get the size of a malloc'ed block.
>>> The answer?  "Remember how much you asked for, dimwit!"
>>
>>Actually, if free() is going to be able to deallocate the space, the
>>dimwit malloc() ought to be salting the size away somewhere, since
>>free doesn't depend on the dimwit programmer telling it how big the
>>block is. With that in mind, there's no conceivable reason why there
>>isn't an msize() function for us comp.unix.dimwits.

I don't agree that only dimwits require this information.  All
implementations of malloc() will give you *at least* the amount of room
you asked for; many will give you more (BSD is reputed to allocate in
powers of 2).  I have several applications where I could make more
efficient use of space if I knew how much space malloc() actually gave
me.  This occurs whenever I am malloc()'ing a buffer that I may want
to realloc() later because it filled up; knowing how much malloc()
actually gave me could save both malloc space and run-time.

I suggested this on comp.lang.c a while back as a useful, portable
enhancement to any malloc() package, but got no response.  I have
redirected follow-ups back to comp.lang.c because it seems of general
interest to users of standard C libraries with a malloc() routine.

-- 
-------------
Brett D. Galloway
{ac6,calma,cerebus,isi,isieng,pyramid,tymix}!wjvax!brett