malloc() & address allocation

Hi there.
I know that malloc() takes its memory chunks from the heap. assuming that there are two consecutive malloc calls, one immedietly after the other, one would assume that the chunks would be allocated nearby like blocks in an array,

what i mean is
//assume sizeof(char)=1
char * p1 = (char*)malloc(sizeof(char)); //now let p1 =1460 (address)
char * p2 = (char*)malloc(sizeof(char));

now p2 should be =1461 (or atleast 1462 for even address boundary), right? but instead, my Turbo Compiler gives the allocated address as 1468 (i.e. an 8 byte gap between the addresses consecutive calls).

experimenting a lot, there always seems to be either a 4 byte or 8 byte gap between the consecutively malloc()'d allocated addresses. , so if we allocated a 3 int array using malloc(3*sizeof(int)), and then one more malloc, the first malloc ()returned address would be 1460, and the second malloc will return 1468.

I searched in the net and found out that ANSI doesnt specify how the memory must be allocated between malloc calls, it is specific to single malloc calls.

could anyone tell me why there is a gap, ?? I do hope u got my doubt....

regards

>one would assume that the chunks would be allocated nearby like blocks in an array
One could assume that, and on many implementations one would be correct. But because the standard doesn't require that malloc return contiguous blocks of memory, the assumption is not portable.

>could anyone tell me why there is a gap
Suitable alignment. The standard only requires that malloc return "at least" as much memory as you ask for, but it's almost always more.

u say it returns more. Does this mean i can use the "gap" to write/read anything and there wont be any "violation" ?

i know the gap might be just anywere from 4 - 6 bytes...

>Does this mean i can use the "gap" to write/read anything and there wont be any "violation" ?
You would be walking on thin ice to be sure. It's strongly recommended that you only use what you asked for originally.

okey dokey.... thanks a lot.

Certainly if you tried to write into that "gap" having the Microsoft debug mode runtime library linked to your program, it'll point out your error when you free the memory, as it allocates slightly more memory than you expect (I mean, beyond normal allocation) in order to detect violations like overruns.

Generally speaking, you should use what you're given rather than try to "cheat" the system. If you want those chars to be contigious, allocate an array of them.

After the (an arbitrary) program runs for a while, there will be many chunks allocated and given back and they will be in abitrary order as far as their next assignment is concerned. Then you cannot even count on the "next" one being at a larger address. Nor can you count on the separation originally used to stay the same. In many implementations there will be a minimum (probably 8) alignment used, but there may well be more space allocated with a before and after frame start and frame end code inserted. If you mess up these you will have exceeded the limits of your space and the program will fail. This helpsto prevent things like indexing past the end or before the start of and array. If you know the implementation you can write a monitor or garbage collector of your own to report memory usage real-time or do automatic garbage collection by "walking the heap" (and in the case of the garbage collector you will also need to walk the stack where there will almost certainly be "frames" used. You should only write into the space you have allocated, but you probably can look at the whole heap - used and unused.