26

I noticed something strange after compiling this code on my machine:

#include <stdio.h>

int main()
{
    printf("Hello, World!\n");

    int a,b,c,d;

    int e,f,g;

    long int h;

    printf("The addresses are:\n %0x \n %0x \n %0x \n %0x \n %0x \n %0x \n %0x \n %0x",
        &a,&b,&c,&d,&e,&f,&g,&h);

    return 0;
}

The result is the following. Notice that between every int address there is a 4-byte difference. However between the last int and the long int there is a 12-byte difference:

 Hello, World!
 The addresses are:

 da54dcac 
 da54dca8 
 da54dca4 
 da54dca0 
 da54dc9c 
 da54dc98 
 da54dc94 
 da54dc88
Boann
  • 109
  • 4
yoyo_fun
  • 2,267
  • 3
  • 17
  • 22
  • 3
    Put another `int` after `h` in the source code. The compiler may put it in the gap, before `h`. – ctrl-alt-delor Sep 12 '17 at 12:48
  • 32
    Don't use the difference between memory addresses to determine size. There's a `sizeof` function for that. `printf("size: %d ", sizeof(long));` – Chris Schneider Sep 12 '17 at 19:46
  • 10
    You're only printing the low 4 bytes of your addresses with `%x`. Lucky for you, it happens to work correctly on your platform to pass pointer args with a format string expecting `unsigned int`, but pointers and ints are different sizes in many ABIs. Use `%p` to print pointers in portable code. (It's easy to imagine a system where your code would print upper/lower halves of the first 4 pointers, instead of lower half of all 8.) – Peter Cordes Sep 13 '17 at 00:41
  • 5
    @ChrisSchneider [to print size_t use `%zu`](https://stackoverflow.com/q/940087/995714). @yoyo_fun [to print addresses use `%p`](https://stackoverflow.com/q/9053658/995714). Using the wrong format specifier invokes [undefined behavior](https://stackoverflow.com/q/16864552/995714) – phuclv Sep 13 '17 at 03:54
  • it's better to declare variables in descending order of size – phuclv Sep 13 '17 at 09:57
  • @LưuVĩnhPhúc why is it better to declare variables in descending order of size? – yoyo_fun Sep 13 '17 at 10:36
  • because there will be no padding => less memory used – phuclv Sep 13 '17 at 11:21
  • Side-note: `long int` really means "a number that can hold values of [−2,147,483,647, +2,147,483,647]" - so it could also be just four bytes. If you want a 64-bit number, you need to use `long long`, as per the C(99) standard (or of course, if you *specifically* want 64 bits, use the 64-bit stdint). Your code is basically one non-standard behaviour after another :) You need to be a lot more careful if you want to seriously code in C in a portable manner. – Luaan Sep 13 '17 at 13:44
  • 2
    @luu don’t spread misinformation. No decent compiler cares about the order in which variables are declared in C. If it cares, there’s no reason why it would do it the way you describe. – gnasher729 Jan 30 '18 at 08:21

3 Answers3

81

It didn't take 12 bytes, it only took 8. However, the default alignment for an 8 byte long int on this platform is 8 bytes. As such, the compiler needed to move the long int to an address that's divisible by 8. The "obvious" address, da54dc8c, isn't divisible by 8 hence the 12 byte gap.

You should be able to test this. If you add another int prior to the long, so there are 8 of them, you should find that the long int will be aligned ok without a move. Now it'll be only 8 bytes from the previous address.

It's probably worth pointing out that, although this test should work, you shouldn't rely on the variables being organised this way. A C compiler is allowed to do all sorts of funky stuff to try to make your program run quickly including re-ordering variables (with some caveats).

Alex
  • 3,882
  • 1
  • 15
  • 16
  • You are correct about the situation on this machine. I added another long int and the difference is only 8 bytes of memory. – yoyo_fun Sep 12 '17 at 11:00
  • 3
    difference, not gap. – Deduplicator Sep 12 '17 at 12:09
  • 10
    "including re-ordering variables". If the compiler decides that you don't use two variables at the same time, it's free to partially overlap or completely overlay them as well... – Roger Lipscombe Sep 12 '17 at 13:01
  • 8
    Or indeed, keep them in registers instead of on the stack. – OrangeDog Sep 12 '17 at 13:30
  • 11
    @OrangeDog I don't think that would happen if the address is taken as in this case but, in general, you are of course correct. – Alex Sep 12 '17 at 13:34
  • @Alex indeed, unless UB is involved (such as using the address after the function returns) – OrangeDog Sep 12 '17 at 13:38
  • 5
    @Alex: You can get funny things with memory and registers when taking the address. Taking the address means it has to give it a memory location, but doesn't mean it has to actually use it. If you take the address, assign 3 to it and pass it to another function, it might just write 3 into RDI and call, never writing it to memory. Surprising in a debugger sometimes. – Zan Lynx Sep 12 '17 at 16:31
  • Right but if you take the address and pass it to a function then in the absense of special knowlage about the internals of said function it has to assume that both the function that was passed the parameter and any later function calls may use and/or modify the value. – Peter Green Sep 12 '17 at 16:57
  • @PeterGreen: True, but you still can get fun results. Such as giving the variable an address only at the last minute, possible even an address that was used earlier for another variable. – MSalters Sep 12 '17 at 22:27
9

This is because your compiler is generating extra padding between variables to ensure they are correctly aligned in memory.

On most modern processors, if a value has an address that is a multiple of its size, it is more efficient to access it. If it had put h at the first available spot, its address would have been 0xda54dc8c, which isn't a multiple of 8, so would have been less efficient to use. The compiler knows about this and is adding a bit of unused space between your last two variables in order to make sure it happens.

Jules
  • 17,614
  • 2
  • 33
  • 63
  • Thanks for the explanation. Can you point me to some materials regarding the reasons for which accessing variables which are multiple of their sizes is more efficient? i would like to know why is this happening? – yoyo_fun Sep 12 '17 at 11:05
  • @yoyo_fun the wikipedia article on data structure alignment that I linked to in my answer has a reasonable explanation. – Alex Sep 12 '17 at 11:21
  • 4
    @yoyo_fun and if you *really* want to understand memory, then there is a famous paper on the subject http://futuretech.blinkenlights.nl/misc/cpumemory.pdf – Alex Sep 12 '17 at 11:26
  • 1
    @yoyo_fun It's quite simple. Some memory controllers can only access multiples of the processor's bit width (e.g. a 32-bit processor can only directly request addresses 0-3, 4-7, 8-11, etc). If you ask for a non-aligned address, the processor has to make two memory requests then get the data into the register. So, back to 32-bit, if you wanted a value stored at address 1, the processor has to ask for addresses 0-3, 4-7, then get the bytes from 1, 2, 3, and 4. Four bytes of memory read wasted. – phyrfox Sep 12 '17 at 14:10
  • 2
    Minor point, but misaligned memory access can be an unrecoverable fault instead of a performance hit. Architecture dependent. – Jon Chesterfield Sep 12 '17 at 23:14
  • 1
    @JonChesterfield - Yes. That's why I commented that the description I gave applies to *most* modern architectures (by which I mostly meant x86 and ARM). There are others that behave in different ways, but they're substantially less common. (Interestingly: ARM *used* to be one of the architectures that required aligned access, but they added automatic handling of unaligned access in later revisions) – Jules Sep 13 '17 at 02:06
2

Your test isn't necessarily testing what you think it is, because there is no requirement of the language to relate the address of any of these local variables to each other.

You would have to put these as fields in a struct in order to be able to infer something about storage allocation.

Local variables are not required to share storage next to each other in any particular manner. The compiler may insert a temporary variable anywhere within the stack, for example, which could be in between any two of these local variables.

By contrast, it wouldn't be allowed to insert a temporary variable into a struct, so if you printed the addresses of struct fields instead, you'd be comparing items intended allocated from the same logical chuck of memory (the struct).

Erik Eidt
  • 33,282
  • 5
  • 57
  • 91