On Jan 12, 2012, at 09:19 AM, Edwards, Waverly wrote:

> Waverly wrote:
> 
>> malloc_size
>> I didn't know this existed.  I've always worked around having to get the size whenever I use malloc.
> 
> malloc_size() may not give the answer you expect. malloc() likes to round up the request size, to a multiple of 16 or greater.


Not Cool... but again, very good to know.

Me:

Wasn't it President Reagan who said "Trust, but verify".

Looks like one should never count on anything but the actual original size asked for and not any returned value from "malloc_size".

Here is the original code from RP with an addition using "calloc" which returns a pointer with enough space for "n" objects of "size", i.e. "calloc( 4, 32 )", or 4 objects of size 32 = 128. With "n" set to 1 it returns the same values as "malloc" but goes up in proportion to "n".

K&R says the "pointer returned by malloc or calloc has the proper alignment for the object in question".

All appearances is a rounding up to the nearest 16 byte value

However "malloc_size" does not return the same value as the original asked for size. Very interesting as to exactly why so I would never assume more than the original values passed.

Changing '32769' to '32768' give the exact value while '32769' adds 512 bytes instead of 16 like askeing for 15 or 17. Odd.

Just FYI and having some fun understanding the particulars.

// - - - - -

include "ConsoleWindow"
BeginCDeclaration
#include <malloc/malloc.h>
EndC
toolbox fn malloc_size( pointer ) = long


local fn Test( size as long )
dim as pointer  p, m, c

p = fn NewPtr( size )
m = fn malloc( size )
c = fn calloc( 1, size )
print fn GetPtrSize( p ), fn malloc_size( m ), fn malloc_size( c )
DisposePtr( p )
free( m )
free( c )
end fn

fn Test( 15 )
fn Test( 17 ) // will become 32 because it's 1 over
fn Test( 97 )
fn Test( 32769 )

// - - - - -