malloc question

[Marshall Cline]

In article <25471 at agate.BERKELEY.EDU> andy at garnet.berkeley.edu (Andy Lieberman) writes:

>In article <25424 at agate.BERKELEY.EDU> ?Andy?Lieberman? wrote:
>>I want to write a function that will return the size of a memory
>>block that was allocated with malloc.  How can I determine this
>>knowing only the pointer to the start of the block? (I know I
>>could keep track myself, but I don't see why I should have to.)
>>I'm using SUNOS 3.5.  
>>

Tony Olekshy (...!alberta!oha!tony or tony at oha.UUCP) replies:
>This is not portable, but most malloc() keep the size of the block in
>an int just before the block (ie, they allocate sizeof(int) more bytes
>than you ask for, and return you a pointer sizeof(int) bytes into the
>block).  So, if p is a char* from malloc, you can usually use something
>like *(int *)(p - sizeof(int)).

>[...more portability warnings deleted...]

Not to be picky, but wouldn't that be a "size_t" rather than an "int"?
Ie: You want the pointer minus "sizeof(size_t)" bytes.  Thus:
	*(int *)((char *)p - sizeof(size_t))
(Note that I added an explicit "(char *)" cast to "p", which Tony
correctly implied in the discussion above).

Again the stern warning: Unportable, unportable, unportable.
The only reason to avoid malloc'ing another extra "sizeof(size_t)"
bytes is convienence (memory is relatively cheap compared to the
increased maintenance cost for unportable code), yet it is _very_
inconvienent to maintain poorly written stuff.
My opinion: Convienence and memory costs are minimal. Do it right.

Note: if you're doing a billion malloc's, one could argue that the
memory savings would be valid.  But if you're doing a billion
memory allocations, there certainly are better alternatives than
a billion malloc()'s (such as a few big malloc's each of which is
chopped up into smaller blocks).  Point being that malloc() is
inefficient (both space-wise and time-wise) when used to allocate
billions of tiny blocks of memory.

Conclusion: Store the size of the memory block (or rather the size
you asked for) in a "size_t" variable rather than peeking and poking.

Marshall
--
	________________________________________________________________
	Marshall P. Cline	ARPA:	cline at sun.soe.clarkson.edu
	ECE Department		UseNet:	uunet!sun.soe.clarkson.edu!cline
	Clarkson University	BitNet:	BH0W at CLUTX
	Potsdam, NY  13676	AT&T:	(315) 268-6591