To find out the names of open files in a process

[Alan J Rosenthal]

In article <1209 at wjvax.UUCP> brett at wjvax.UUCP (Brett Galloway) writes:
[ 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.  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 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.  For definiteness, I just verified this by looking at the
sources for Sun Unix 3.3, but I can't imagine a non-silly
implementation in which this would not be true.

In fact, I'd make a case for realloc() being a no-op if the realloc()
value is only slightly less than the original allocation.  In other
words, if you asked for 100 bytes before, and now you realloc() that
to 90, maybe realloc() should say "well it's not worth the bother to
reduce it".  (This would be legitimate behaviour as you can always give
the user MORE memory than they've asked for.)

Also in fact, Sun 3.3 realloc() seems to do that, although it appears
to have been an oversight rather than a deliberate decision, and it
only gives you a 4-byte leeway.  (Details:  The "smallest block" is
defined as an unsigned int plus an array 4 of char, 4 being the deduced
alignment requirement as it is sizeof(int).  The test in realloc() for
whether or not it should do anything is
	    if (oldsize - newsize >= SMALLEST_BLK)
, where SMALLEST_BLK is sizeof(struct { unsigned int size; char data[4]; }).)

ajr