This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC 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]

RE: why there is no memlen();


Many of the heap managers that I know about will only allocated blocks
of certain sizes or on certain boundaries (such as 8 byte boundaries).
Many also have a "minimum" allocation unit (some as high as 32 bytes).
These ideas help speed up the allocation and deallocation of memory.

Some of these managers can/will tag the beginning/end of blocks of
allocated memory with patterns. These patterns are used during
allocation/deallocation to see if the heap is corrupt.

I am not sure what the odd memory allocations (105 * 10009) are
mentioned below, but if you have a good memory debugger, you might be
able to look and see what is at those locations and tell what it is used
for.




> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org]
On
> Behalf Of John Love-Jensen
> Sent: Thursday, October 31, 2002 7:59 AM
> To: Arunachalam G
> Cc: gcc-help@gcc.gnu.org
> Subject: Re: why there is no memlen();
> 
> Hi Arun,
> 
> > What is that? going 4 bytes back & reading it give the amount of
memory
> > allocated.
> 
> It's how the heap manager keeps track of the lengths of the allocated
> blocks.  Note:  not ALL heap managers use this particular bookkeeping
> trick.
> 
> > does it contains the attributes of the data type.
> 
> Hmmm, I suspect the answer is "no".
> 
> > and why it is compiler specific?
> 
> There are other ways to manage heaps.  If you were writing your own
heap
> manager, you could (for instance) put the bookkeeping information in
an
> entirely separate block of memory.
> 
> Or perhaps you have a debugging heap manager that NEVER returns memory
to
> the pool, so it doesn't need to keep track of lengths.  [Not
recommended
> for
> production code!]
> 
> > I use gcc 2.95.4 on linux in IA32. The above code gave some more
> addtional
> > length than the actually allocated. (for 100 bytes it gave 105 & for
> 1000
> > it gave 1009). Is it due to alignment?
> 
> Uncertain, but that sounds plausible.
> 
> --Eljay
> GCC 3.2 on Cygwin
> GCC 3.1 on OS X
> GCC 2.95.2 on Solaris


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