www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/05/20/19:16:59

Sender: nate AT cartsys DOT com
Message-ID: <374498CD.C32D1A1C@cartsys.com>
Date: Thu, 20 May 1999 16:20:45 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.5 i586)
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: Heap-Memory Function
References: <199905202123 DOT RAA11152 AT mccoy2 DOT ECE DOT McGill DOT CA>
Reply-To: djgpp-workers AT delorie DOT com

Alain Magloire wrote:
> 
> Bonjour
> 
> > Years ago when I worked with Microsoft C/C++, I used a function
> > called _msize().  Its purpose was to return the size of a block
> > of memory allocated on the heap.  I found this very handy when
> > tracking memory allocations and, especially, leaks and pointer
> > misuse.
> 
> 8-)
> Sorry I could not help smiling.  I just finish implementing an allocator
> for an RTOS, and usually when people ask me for ways to get back the
> size, it is for all the wrong reasons (I'm not saying that you
> don't have some valid ones)
> 
> Most of the time the information block is hold in an offset, -1 of the pointer.
> So p = malloc(40), you should get the size by moving back 1 and casting
> to the appropriate struct.  Ususally the size will be the
> last field in the structure so you don't have to guess the offset.
> So something like this .. might work.

It looks like the int at offset -1 indeed.  Note that the low bit
appears to be used for something else; you should mask it to 0.

<plug>
If you have memory bugs, you could try my YAMD malloc debugger.  It
still has a few problems but should work fine for most things
(especially if they are plain C).  See:
http://www.cartsys.com/eldredge/n/yamd/
</plug>
-- 

Nate Eldredge
nate AT cartsys DOT com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019