Antoninus> The only reason I can think of why someone may want to to
Antoninus> this is to save memory by being able to store pointers in
Antoninus> 32 bits instead of 64. In this case, the obvious (ugly)
Antoninus> solution is to store a 64-bit "base" pointer, and then
Antoninus> instead of storing pointers to struct nodes (or whatever)
Antoninus> inside the array starting at base(*), you store 32-bit
Antoninus> (or even 16-bit) offsets.
<
i.e. doing segmented addressing on your own.
But that doesn't require any distinction between 32-bit or 64-bit heaps
(actually, there are no such separate heaps at all). I often use this
technique to manage my own data pools with fewer than 256 (or 65536)
objects, so that the object id's are short enough (only 8-bit or 16-bit
long) to make other data structures compact. There is absolutely no
need to bother with sizeof(void*) at all.
So, the question again: why would the OP want to handle 32-bit (which
doesn't exist) and 64-bit heaps separately? What is the intention?
though, technically OT for this group, I will mention that mmap provides a
flag specifically for the purpose of allocating in the low 4GB of address
space, and yes, there are some uses for this (primarily, it is useful when
doing custom compilation and linking, as x86-64 machine code typically uses
32-bits for addresses and immediates and similar, and so linking all of the
code into the lower 4GB allows a compiler to generate faster and more
compact code).
as for the 32-bit local-heap idea, yes, this is a workable approach for
data, but as can be noted, does have the cost of likely requiring data to be
accessed via handles (the local offsets).