Quoting Frank Adam to All:



 FA> {at}MSGID: 3:635/544.0 31c54cf8

 FA> Hi,



 FA> Tested in TC2 and BC4, worked correctly in both.

 FA> This function will return the size of the memory block held by a

 FA> pointer. It will do a realloc too, according to parameter 2 and 3.     

 FA> 

 FA> Keeping in mind it's Borland specific code, but other compilers may

 FA> have  a similar function. 

 FA> I also found that in Borland the size of the data is at ptr-4h, where 

 FA> that byte is the low byte and the following byte(ptr-3) is high byte.

 FA> Perhaps the following two bytes are reserved for 32 bit environments,

 FA> but they have some values in them. This i came upon when i've noticed

 FA> that heapwalk returns the malloced size + 4. 

 FA> Had to rewrite it to put it through Pacific C, but the idea does not

 FA> work  there , so it seems it's the RTL doing the shuffle not the OS.   



That's understandable; if you malloc'ed a 2-byte variable (don't ask _why_

you would...) DOS would use 32 bytes. Just a bit inefficient.



FWIW, a block of memory allocated by DOS has its size stored at (s-1):3,

where s is the segment returned in AX by the mov ah,48h; int 21h call.

So memory allocated by DOS will have the (char)(ptr-16) as 'M' or 'Z' and

(short)(ptr-13)<<4 will be the size of the memory block (shifted 4 bits

to the left because it's stored as a number of paragraphs, ie 16-byte

blocks).



... A program is used to turn data into error messages.

--- FMailX 1.02