Memory Allocation in Stack

[aakashjohari]

Hello All,
I have written the following code. I have declared 2 arrays t and s both of size of 4 integers and two integer variables u and i. Please pay attention to the order they have been declared. In the following code, I have printed out the addresses of each array element and variable in the opposite sequence in that they have been declared (s, i, u, t).

# include <stdio.h>
# include <string.h>

int main()
{
	int t[4] = {10, 30, 50, 20}, u = 5;
	int i;
	int s[4] = {90, 44, 23, 76};

	for ( i = 0; i < 4; i++ ) {
		printf ("s[%d] = %u, %d\n", i, s + i, s[i]);
	}

	printf ("i = %u, %d\n", &i, i);

	printf ("u = %u, %d\n", &u, u);
	
	for ( i = 0; i < 4; i++ ) {
		t[i] = i;
		printf ("t[%d] = %u, %d\n", i, t + i, t[i]);
	}

	return 0;
}

The output of the program is as follows:

s[0] = 3216459112, 90
s[1] = 3216459116, 44
s[2] = 3216459120, 23
s[3] = 3216459124, 76
i = 3216459128, 4
u = 3216459132, 5
t[0] = 3216459136, 0
t[1] = 3216459140, 1
t[2] = 3216459144, 2
t[3] = 3216459148, 3

It means they have been allocated memory in this order only(reverse of the order in which they have been declared). Can It change on different compiler or OS?

Operating System: Linux (Mandriva 2010)
Compiler: gcc 4.4.1

Thanks and Best Regards,
Aakash Johari

[Salem]

Absolutely.
There is no guarantee that the declaration order of distinct variables has anything to do with the allocation order, or the size of any padding between distinct variables.

You can only meaningfully compare addresses between
- elements of the same array
- members of the same struct/union

[aakashjohari]

Absolutely.
There is no guarantee that the declaration order of distinct variables has anything to do with the allocation order, or the size of any padding between distinct variables.

You can only meaningfully compare addresses between
- elements of the same array
- members of the same struct/union

But please go through this link.

It says that memory allocation goes contiguous even for the statically defined variables.

How Stuff Works

Thanks and Best Regards,
Aakash Johari

[Bayint Naung]

Drop that site. Grab a better tutorial/book like The C Book - Table of Contents,
The C programming language

Read the c-iaq

1.3: If I write the code int i, j; can I assume that (&i + 1) == &j?

Only sometimes. It's not portable, because in EBCDIC, i and j are not adjacent. [a]

[Salem]

Forget that site - read the standard if you want a real answer.
http://www.open-std.org/jtc1/sc22/wg...69/n869.pdf.gz

When two pointers are compared, the result depends on the relative locations in the
address space of the objects pointed to. If two pointers to object or incomplete types both
point to the same object, or both point one past the last element of the same array object,
they compare equal. If the objects pointed to are members of the same aggregate object,
pointers to structure members declared later compare greater than pointers to members
declared earlier in the structure, and pointers to array elements with larger subscript
values compare greater than pointers to elements of the same array with lower subscript
values. All pointers to members of the same union object compare equal. If the
expression P points to an element of an array object and the expression Q points to the
last element of the same array object, the pointer expression Q+1 compares greater than
P. In all other cases, the behavior is undefined.

[EVOEx]

But please go through this link.

It says that memory allocation goes contiguous even for the statically defined variables.

How Stuff Works

Thanks and Best Regards,
Aakash Johari

I haven't read the site, but I disagree that you shouldn't know that stuff. Just remember that it's not portable and you shouldn't rely on it on C code, that doesn't mean the knowledge can't be useful. I have found it very useful, however rarely. Especially to debug things like buffer overflows.
Just, whatever yo do: do not rely on it! Ever!

[nonoob]

Within a single integer, its bytes are contiguous. As well, for arrays, structs, their elements are allocated contiguously.

"When the program runs, the computer reserves space for the variable f somewhere in memory."
- This is correct. It also means that declaration of multiple variables can end up anywhere in memory.

Their example shows the compiler chose to allocate the variables in the same order as written in the source code. This is not guaranteed. It may be true for some compilers. The C standard does not define correlation between memory address order and source code variable order.

Their main point was that accessing an array outside of its bounds will likely access memory contents belonging to other variables since variables all occupy some area of memory.

[CommonTater]

The output of the program is as follows:

s[0] = 3216459112, 90
s[1] = 3216459116, 44
s[2] = 3216459120, 23
s[3] = 3216459124, 76
i = 3216459128, 4
u = 3216459132, 5
t[0] = 3216459136, 0
t[1] = 3216459140, 1
t[2] = 3216459144, 2
t[3] = 3216459148, 3

It means they have been allocated memory in this order only(reverse of the order in which they have been declared). Can It change on different compiler or OS?

And, you would care about any of this exactly why???

Really... what possible difference can it make where the data is actually stored in memory or what order it's in? You know how to access it through variables in your code, that's all that matters.

[anduril462]

You can only meaningfully compare addresses between
- elements of the same array
- members of the same struct/union

Members of the same struct/union will always appear in the same order with the same distance between them, but they might not be contiguous since certain types have to be aligned and thus the compiler may insert padding to achieve this, e.g.

#include <stddef.h>
#include <stdio.h>

struct foo {
    char bar;
    int baz;
};

int main(void)
{
    printf("offsetof(struct foo, bar): %d\n", offsetof(struct foo, bar));
    printf("offsetof(struct foo, baz): %d\n", offsetof(struct foo, baz));

    return 0;
}

[nonoob]

That's correct. In the struct's case, "contiguous" is a slight exaggeration. Its elements are still in the order they appear, as in having ever increasing addresses, but default padding to machine word boundaries may introduce gaps. Unless some #pragma pack(1) or other compiler directive specifically suppresses padding. Then they would be truly contiguous.