-3

If we take the following code:

int height = 10;
int width = 5;
printf(
    "The memory address of height is: %p\n"
    "The memory address of width is:  %p\n",
    &height, &width
);

I get the following prints:

The memory address of height is: 0x7ffeed809a78
The memory address of width is:  0x7ffeed809a74

I was expecting the width to be at location 0x7ffee8843a7c. In other words it's doing &height - 1 instead of &height + 1. Why is that so?

  • 3
    There are no guarantees whatsoever where and in which order the memory locations for these variables are located, but it is quite common for automatic variables to be on the stack, which usually _grows down_. So, later declared variables have lower addresses. – Ctx Sep 02 '19 at 23:05
  • 2
    @Ctx, It's irrelevant in which direction the stack grows because memory isn't reserved from the stack one variable at a time. – ikegami Sep 02 '19 at 23:34
  • @ikegami Yes, but the compiler often distributes the location of the variables inside the buffer according to the natural order of the underlying buffer. As I said, a compiler can in principle do it in any order, but do you think that it is pure coincidence, that for example my gcc assigns _ascending_ variable addresses when these are allocated on the bss, and descending adresses on the stack? – Ctx Sep 03 '19 at 08:33

1 Answers1

2

There's no reason for them to be, so the compiler does what's best for itself.

Complex compiler optimizations and efficient and linear memory layout don't all go together, so linear memory layout was sacrificed.

When you get to hashtables, you will learn how the most efficient algorithms lead to repeatable pseudo-random output order. The symbol names are loaded into a hashtable when compiling; and the function memory space could laid out by iterating over the global symbol table, which is therefore in some arbitrary order.

In general you will find this is true. Whenever the order isn't specified it will be let to fall however, and when algorithms are non-trivial, however isn't simple anymore.

Don't ever depend on order of symbols in memory layout. It's not allowed.

Joshua
  • 40,822
  • 8
  • 72
  • 132
  • 1
    Inside a `struct`, members are allocated in order (although there might be padding between them). – rici Sep 02 '19 at 23:51
  • 1
    Depending on the order of symbols is not actually not allowed. It is just not supported by the C standard. We should not promulgate the false notion that things not supported by the C standard are not allowed. The C standard permits and invites extensions, so may things that are not supported by the standard are supported by specific implementations. That would not be possible if extensions were not allowed. It is correct to say the C standard does not guarantee the order of symbols or support relying on them, but it is not correct to say it is not allowed. – Eric Postpischil Sep 02 '19 at 23:51
  • @EricPostpischil: You and I have a different meaning of "not allowed". If somebody actually needed extensions I would say "specify your compiler". – Joshua Sep 03 '19 at 00:04
  • @Joshua: Please show me the text in the standard that says relying on the order of symbols is not allowed. (Also, my comment above has a typo: “so may things” should be “so many things”.) – Eric Postpischil Sep 03 '19 at 00:45