Paul Sander wrote :
|| >But if no memory is actually allocated, how do you ensure that the
|| >address of the zero-length chunk is different? Since it didn't use
|| >any memory, the same memory address is still free and is likely to be
|| >returned as the result of the next allocation request too. Rather
|| >than trust the alloc routine to carry out an impossible task for
|| >which it was not desgined, you are better off the allocate a real
|| >memory area for unique flag values to ensure they are unique.
||
|| The semantics of the memory allocator include the notion that the addresses
|| of each allocated memory block be unique. That means that a pointer to a
|| block of 0 allocated bytes must be distinguishable from all other pointers
|| produced by the memory allocator.
||
|| How this is done is left as an exercise, but you can pretty much assume that
|| each memory block has some overhead associated with it (as is currently the
|| case for non-zero-sized blocks). Take for example the case where the
|| allocator writes fences into larger blocks of memory as a means of testing
|| the integrity of the heap. If the application asks for 0 bytes then there is
|| no space between the fences.
||
|| Even if no fences are used, most implementations allocate more space than is
|| requested to keep proper alignment of each segment, so if you ask for 0 bytes,
|| you really get more than that (just as if you ask for one byte, you really get
|| more than that).
I understand that it is possible to write an allocator that does
allocate real space; but somewhere earlier in the thread someone
was talking about not actually using any space while still getting
the unique pointers. Looks like I read too much into that.
--
Sleep should not be used as a substitute | John Macdonald
for high levels of caffeine -- FPhlyer | [EMAIL PROTECTED]
