This is the mail archive of the
mailing list for the binutils project.
Re: Is it ok to "leak" modest amounts of objalloc memory?
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Bernd Jendrissek <bernd dot jendrissek at gmail dot com>
- Cc: binutils <binutils at sourceware dot org>
- Date: Thu, 18 Aug 2011 17:46:19 -0400 (EDT)
- Subject: Re: Is it ok to "leak" modest amounts of objalloc memory?
- References: <CAF7PVPo2o58rqBu8mmxX6rOVT-VC4h3fbQPrOopgdQmN_HOkRg@mail.gmail.com>
On Thu, 18 Aug 2011, Bernd Jendrissek wrote:
> 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.
Having no idea what counts as a category in that context, I'll
just assume that it's typically less than ten per object file
and that you're typically not looking at more than about 128KiB
per object file; not more than 1M even for big files. Right?
I wouldn't worry about it. Regarding maintanance, just put a
comment above the bfd_alloc call mentioning that the memory is
not freed until <whatever>.