🚀 go-pugleaf

>> Because of the ANSI restrictions on pointers, it is not
>> safe to compare them in this way (in fact, neither of the C compilers
>> I have at home do this job with pointers).
>
>Let me guess... you have an IBM-PC at home? Well, *THAT* is the machine
>responsible for the ANSI restrictions on pointers *in portable code*.

I hope that's not the only reason!  I would be more concerned about people
doing things like trying to figure which variables are n bss and which are in
the data segment (in your favorite Unix linear address space) by merely
comparing their addresses and assuming the higher one was bss.  Or assuming
that two consecutively defined global variables X and Y might have the
interesting property that (char *)&y - (char *)&x = sizeof(x).  None of which
is true in any but the most simple minded linearly addressed architectures.

These assumptions were in fact made in two widely known "malloc" algorithms for
Unix, and they both break on any system that doesn't have the most basic
address space.  For instance, many Unix implementations in which "malloc"
resides in a shared library.

In any case, a portable memory manager can deal with doling out chunks of an
internal memory pool.  Additional pools can non-portably be obtained through
calls to sbrk() on Unix, but the memory manager is free to compare pointers
within each pool.  It cannot portably inquire whether one pool is "higher" or
"lower" in memory than another, but if the pools are indeed acquired via sbrk()
then you know darn well based on the acquisition order which is "higher".  The
only trouble is determining from which pool a pointer about to be free'd came
from, but that is only if you weren't clever to put that information in the
the header of the allocated block your pointer is pointing into.