gcc中的c内存管理

Question

I am using gcc version 4.7.2 on Ubuntu 12.10 x86_64.

First of all these are the sizes of data types on my terminal:

sizeof(char) = 1    

sizeof(short) = 2          sizeof(int) = 4
sizeof(long) = 8           sizeof(long long) = 8

sizeof(float) = 4          sizeof(double) = 8
sizeof(long double) = 16

Now please have a look at this code snippet:

int main(void)
{   
    char c = 'a';
    printf("&c = %p\n", &c);
    return 0;
}

If I am not wrong we can't predict anything about the address of c . But each time this program gives some random hex address ending in f . So the next available location will be some hex value ending in 0 . I observed this pattern in case of other data types too. For an int value the address was some hex value ending in c . For double it was some random hex value ending in 8 and so on.

So I have 2 questions here.

1) Who is governing this kind of memory allocation ? Is it gcc or C standard ?

2) Whoever it is, Why it's so ? Why the variable is stored in such a way that next available memory location starts at a hex value ending in 0 ? Any specific benefit ?

Now please have a look at this code snippet:

int main(void)
{   
    double a = 10.2;
    int b = 20;
    char c = 30;
    short d = 40;

    printf("&a = %p\n", &a);
    printf("&b = %p\n", &b);
    printf("&c = %p\n", &c);
    printf("&d = %p\n", &d);

    return 0;
}

Now here what I observed is completely new for me. I thought the variable would get stored in the same order they are declared. But No! That's not the case. Here is the sample output of one of random run:

&a = 0x7fff8686a698
&b = 0x7fff8686a694
&c = 0x7fff8686a691
&d = 0x7fff8686a692

It seems that variables get sorted in increasing order of their sizes and then they are stored in the same sorted order but with maintaining the observation 1. ie the last variable (largest one) gets stored in such a way that the next available memory location is an hex value ending in 0 .

Here are my questions:

3) Who is behind this ? Is it gcc or C standard ?

4) Why to waste the time in sorting the variables first and then allocating the memory instead of directly allocating the memory on 'first come first serve' basis ? Any specific benefit of this kind of sorting and then allocating memory ?

Now please have a look at this code snippet:

int main(void)
{   
    char array1[] = {1, 2};
    int array2[] = {1, 2, 3};

    printf("&array1[0] = %p\n", &array1[0]);
    printf("&array1[1] = %p\n\n", &array1[1]);

    printf("&array2[0] = %p\n", &array2[0]);
    printf("&array2[1] = %p\n", &array2[1]);
    printf("&array2[2] = %p\n", &array2[2]);

    return 0;
}

Now this is also shocking for me. What I observed is that the array is always stored at some random hex value ending in '0' if the elements of an array >= 2 and if elements < 2 then it gets memory location following observation 1.

So here are my questions:

5) Who is behind this storing an array at some random hex value ending at 0 thing ? Is it gcc or C standard ?

6) Now why to waste the memory ? I mean array2 could have been stored immediately after array1 (and hence array2 would have memory location ending at 2 ). But instead of that array2 is stored at next hex value ending at 0 thereby leaving 14 memory locations in between. Any specific benefits ?

Answer 1

The address at which the stack and the heap start is given to the process by the operating system. Everything else is decided by the compiler, using offsets that are known at compile time. Some of these things may follow an existing convention followed in your target architecture and some of these do not.

The C standard does not mandate anything regarding the order of the local variables inside the stack frame (as pointed out in a comment, it doesn't even mandate the use of a stack at all). The standard only bothers to define order when it comes to structs and, even then, it does not define specific offsets, only the fact that these offsets must be in increasing order. Usually, compilers try to align the variables in such a way that access to them takes as few CPU instructions as possible - and the standard permits that, without mandating it.

Answer 2

Part of the reasons are mandated by the application binary interface (ABI) specifications for your system & processor.

See the x86 calling conventions and the SVR4 x86-64 ABI supplement (I'm giving the URL of a recent copy; the latest original is surprisingly hard to find on the Web).

Within a given call frame, the compiler could place variables in arbitrary stack slots. It may try (when optimizing) to reorganize the stack at will, eg by decreasing alignment constraints. You should not worry about that.

A compiler try to put local variables on stack location with suitable alignment. See the alignof extension of GCC. Where exactly the compiler put these variables is not important, see my answer here . (If it is important to your code, you really should pack the variables in a single common local struct , since each compiler, version and optimization flags could do different things; so don't depend on that precise behavior of your particular compiler).