To find out the names of open files in a process

[Ray Butterworth]

In article <1209 at wjvax.UUCP>, brett at wjvax.UUCP (Brett Galloway) writes:
> 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.

My buffer growing applications typically look something like this:

dosomething(size_t bytes_needed, other-args) {
    static size_t bytes = 0;
    static char *buffer = 0;

    if (bytes_needed > bytes) {
        if (buffer)
            free((malloc_t)buffer);
        while (bytes < bytes_needed)
            bytes = (bytes*2) + 4;
        buffer = (char *)malloc(bytes);
        if (!buffer) {
            perror("malloc");
            exit(ERROR_EXIT);
        }
    }

    finally-do-it;
    return;
}

The "(bytes*2)+4" is based on the BSD malloc growth.
The algorithm would be very wasteful on many other systems,
but anything else would be very wasteful on all systems.

> 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.

Being able to determine the appropriate growth increment at run-time
(or even compile-time) would defintely be useful.