Yes, people love to argue with the term "heap". Yackety yack, but it does not improve functional understanding.

Everything but the stack comes out of the address space at the bottom, starting with code load, initial dynamic library load (which is mmap()), globals, statics; all as the sections they are in are encountered, and then dynamic additions: ld() calls laying down dynamically linked (again via mmap()), malloc/calloc/realloc(), explicit mmap(), object new, etc. If you mmap(), the files under this VM are not the swap, but the mmap()'d file's area. Everyone executes the same RAM pages of /lib/libc.so, for instance, but possibly at different local VM offsets.

The stack grows down from the top of the address space, with subroutine parameters, automatic variables, allloca() calls (deprecated but deliciously cheap since return does an implicit free()). While automatic arrays are stored here, automatic pointers are here but initialization objects they point to are mostly not here. Space is allocated with calls and automatic declarations and freed with return, and the return value overwrites/redefines the 'top' of the stack. The language metaphors of the stack like tops are "heap-esque", since it is a metaphor for a stack of sheets of paper, but it was handy to allocate it down from the top. Most systems have CPU binary info on the same stack, to restore state on return. Sometimes registers are pushed on call and restored on return. This way, each lower level subroutine gets the free use of registers it needs without first saving and finally restoring the content, when the content might be worthless. Compilers can assign call/return parameters to registers for the call of the bottom level subroutines, saving RAM activity on the stack in the inner parts of loops.

Sometimes the CPU hardware stack is not friendly to programmer data, and the stack is realloc()'d on the heap, and so grows upward.

A system might have an odd allocation scheme where the VM is subdivided into pieces that can all grow independently from the bottom without the restriction of items being allocated in the way. Some systems use segmentation, where the virtual memory is divided into N separate spaces. The problem is, usually these spaces are not big enough, or too few, and the schemes usually shrink the segment space when they devote address bits to the segment number. The x86 segmentation, as I recall, can have 16384 segments, half nominally for the system, and they span a million either bytes or 4KB pages, but in the latter case length is enforced only to the page. In unsegmented space, a really bad offset on a pointer to the stack can look into a legally readable part of the heap. UNIX generally always uses unsegmented space.

Yes, comparing addresses of items not in the same array is nonsense, except as research, for instance if you desire to do some raw binary i/o. Even then, it is nicer to make a struct or object for such purposes, using #pragma pack if you dislike the amount of padding/alignment. Beware of the other-endian systems!