This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
RE: why there is no memlen();
- From: "Buddy Lott" <buddy_lott at hotmail dot com>
- To: <gcc-help at gcc dot gnu dot org>
- Date: Thu, 31 Oct 2002 08:15:35 -0500
- Subject: 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