RE: Is it ok to "leak" modest amounts of objalloc memory?

[<Paul_Koning at Dell dot com>]

>I am working on OMF support, and I need to do the equivalent of
>realloc(3) when resizing string tables.  Using bfd_alloc() simplifies my code greatly, as I don't have to worry about deallocating memory when I'm done using it - relying on the call to bfd_release in my _bfd_check_format hook.  Unfortunately there seems to be no way to resize an existing allocation - so in effect I'd be "leaking" memory (that is, only until the end of _bfd_check_format) on certain object files that trigger array resizes.

>Due to the nature of the target, there's not a whole lot of memory I can leak; OMF indexes run from 1 to 65535, so the amount of memory wasted in resizes is limited to 128KiB per category.  One could also conceive of pathological object files that would waste many many times this amount, by, for example, having 65535 segments, with each having
>65535 relocations.  But I don't expect such files to be at all common!

>With desktop systems nowadays sporting multiple gigabytes of RAM, I'm tempted to just waste a few hundred KiB and quit worrying about it.
>Besides, the wasted memory would total no more than that which is unwasted - I'd just double the buffer size each time it runs out of space.  How do other binutils folk feel about this sort of issue?

It seems like a small thing, but it also feels like a bad precedent.  How would a future maintainer know that this is a "little leak" and ok, while the exact same code cut & pasted to a different situation is not ok because there the leak is much larger?  Better to fix the underlying machinery to provide the facility you need.

	paul