Programming

int a=1;
int b=2;
for the example with &a-&b = 1, can you explain how the pointer math (where its relative to the base size) works and how its different from normal math arithmetics, and why it becomes 1.

for this example i get
&a = -1078176900
and
&b = -1078176904

They're integers, and the address of a is precisely one sizeof(int) away from the address of b. It's that simple.

They're not really negative numbers. Since they're in stack space their addresses are very high, and end up flipping over to negative when you print them as signed integers. Try %x or %u instead of %d. (or really, to be portable, you should use %p).

even through the addresses are negative, why does %x (convert to hex) make it positive? is it because %x expects only unsigned integers, and since this is c, integers are signed on default, so the conversion will think the leftmost bit is part of the numbers magnitude, thus making the hex a positive always?

Look at it this way. Is this group of 32 bits signed or unsigned?

Code:

11111111111111111111111100000000

by itself it's neither... Whether it's signed or not is wholly up to how you interpret it.

When you print it as a %d, it assumes the bit in red is the sign bit, meaning that bit adds -2147483648. It even does this if you try to print an unsigned int with %d.

When you print it as %x or %u, it just considers that bit +2147483648.

So, whether the variable's signed or not, it's just a 32-bit "thing" as far as printf's concerned, it formats it according to how you tell it to.

Heaps are allocated up from 0 and stacks down from the virtual address range ceiling, so subsequent allocations go opposite ways. This should usually exceed ( 3,000,000,000 / 4 ) if it does not overflow the accumulator:

Code:

{
 static int heap ;
 int stack ;
 printf( "%u\n", &stack-&heap );
}

I don't think the way you are using this term is common. Most of the time when people refer to "the heap" of a program, they mean the area(s) from which dynamic memory is allocated (malloc()/calloc()/realloc() in C with new/delete added in C++).

Your variable named "heap" is static and uninitialized, so it will commonly be stored in a "BSS" area which is allocated and fixed at program startup time. Dynamically allocated memory can be (but does not need to be) obtained using (s)brk(), which is a legacy way that indeed implies a block area of dynamic memory. However, the more modern mmap() interface to obtain memory may behave in a completely different manner and grab pages from varying distinct locations (one obvious newfangled justficiation comes to mind immediately: address space randomization), and that's what many modern malloc() implementations use instead of (s)brk().

Also, the issue is even less clear-cut in multithreaded applications - which have more than one stack.

Counter example: HP-UX, where the stack "grows upwards".

To summarize, address space layout is strongly system-specific and it is rarely possible, meaningful or useful to generalize its characteristics.

What point were you trying to make?

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!