This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]