If the stack grows at numerically lower address why does pointer comparison reverses this?

Question

Since the stack grows downwards, ie towards numerically smaller memory addresses why does &i < &j is true. Correct me if I'm wrong, but I'd imagine this was a design decision of C creators (that C++ maintains). But I wonder why though.

It is also strange that a heap-allocated object pin lies at numerically higher memory address than a stack variable and this also contradicts the fact that the heap lies at numerically smaller memory addresses than the stack (and increases upwards).

#include <iostream>

int main()
{
    int i = 5;                  // stack allocated
    int j = 2;                  // stack allocated
    int *pi = &i;               // stack allocated
    int *pj = &j;               // stack allocated

    std::cout << std::boolalpha << '\n';
    std::cout << (&i < &j) && (pi < pj) << '\n';            // true
    struct S
    {
        int in;
    };
    S *pin                      // stack allocated
        = new S{10};            // heap allocated
    std::cout << '\n' << (&(pin->in) > &i) << '\n';         // true
    std::cout << ((void*)pin > (void*)pi) << '\n';          // true
}

Am I right so far and if so why C designers reversed this situation that numerically smaller memory addresses appear higher (at least when you compare the pointers or through the addressof operator &). Was this done just 'to make things work'?

It's Unspecified Behavior to compare the address of elements that are not part of the same array, other than for (in)equality. The result is determined by your platform/implementation. — François Andrieux, Sep 03 '19 at 14:16
Try comparing the addresses of variables in two different stack frames, e.g. pass `pj` into a function an compare it to the address of a local variable in that function — Caleb, Sep 03 '19 at 14:17
Mandatory linked Q&A https://stackoverflow.com/questions/31774683/is-pointer-comparison-undefined-or-unspecified-behavior-in-c — StoryTeller - Unslander Monica, Sep 03 '19 at 14:18
@FrançoisAndrieux Is it really undefined, or just meaningless? I'd think that you could compare pointers just fine, but since the placement of variables in memory is entirely the compiler's business, your program shouldn't care what the result of most comparisons is. — Caleb, Sep 03 '19 at 14:19
@Caleb The standard explicitly says it's unspecified. Each implementation defines it's own rules, but they need to define *some* rules. You must have caught my comment between edits. — François Andrieux, Sep 03 '19 at 14:21

eerorika · Accepted Answer · 2019-09-03T15:05:08.313

9

Correct me if I'm wrong, but I'd imagine this was a design decision of C creators

It is not part of the design of the C language, nor C++. In fact, there is no such thing as "heap" or "stack" memory recognised by these standards.

It is an implementation detail. Each implementation of each language may do this differently.

Ordered comparisons between pointers to unrelated objects such as &i < &j or (void*)pin > (void*)pi have an unspecified result. Neither is guaranteed to be less or greater than the other.

For what it's worth, your example program outputs three counts of "false" on my system.

edited Sep 03 '19 at 15:05

answered Sep 03 '19 at 14:23

eerorika

232,697
12
197
326

What system is that? – KeyC0de Sep 03 '19 at 14:23
@Nikos Linux stacked-crooked 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux with compiler g++ (GCC) 9.2.0 – eerorika Sep 03 '19 at 14:24
Ok. I just checked a Kali 4.15 x64 system with g++ 7.3.0 and it outputs `true`, `false`, `false`. – KeyC0de Sep 03 '19 at 14:44

score 8 · Answer 2 · answered Sep 03 '19 at 14:13

8

The compiler generated code that isn't allocating space for each individual variable in order, but allocating a block for those local variables, and thus can arrange them within that block however it chooses.

answered Sep 03 '19 at 14:13

Scott Hunter

48,888
12
60
101

score 1 · Answer 3 · answered Sep 03 '19 at 14:15

Usually, all the local variables of one function are allocated as one block, during function entry. Therefore you will only see the stack growing downward if you compare the address of a local variable allocated in an outer function with the address of a local variable allocated in an inner function.

score 1 · Answer 4 · answered Oct 11 '19 at 14:29

It's really rather easy: such a stack is an implementation detail. The C and C++ language spec doesn't even need to refer to it. A conforming C or C++ implementation does not need to use a stack! And if it does use a stack, still the language spec doesn't guarantee that the addresses on it are allocated in any particular pattern.

Finally, the variables may be stored in registers, or as immediate values in the code text, and not in data memory. Then: taking the address of such a variable is a self-fulfilling prophecy: the language spec forces the value to a memory location, and the address of that is provided to you - this usually wrecks performance, so don't take addresses of things you don't need to know the address of.

A simple cross-platform example (it does the right thing on both gcc and msvc).

#ifdef _WIN32
#define __attribute__(a)
#else
#define __stdcall
#endif

#ifdef __cplusplus
extern "C" {
#endif
__attribute__((stdcall)) void __stdcall other(int);

void test(){
    int x = 7; 
    other(x);
    int z = 8;
    other(z);
}

#ifdef __cplusplus
}
#endif

Any reasonable compiler won't put x nor z in memory unnecessarily. They will be either stored in registers, or will be pushed onto the stack as immediate values.

Here's x86-64 output from gcc 9.2 - note that no memory loads nor stores are present, and there's tail call optimization!

gcc -m64 -Os

test:
        push    rax
        mov     edi, 7
        call    other
        mov     edi, 8
        pop     rdx
        jmp     other

On x86, we can force a stdcall calling convention that uses stack to pass all parameters: even then, the value 7 and 8 is never in a stack location for a variable. It is pushed directly to the stack when other gets called, and it doesn't exist on the stack beforehand:

gcc -m32 -fomit-frame-pointer -Os

test:
        sub     esp, 24
        push    7
        call    other
        push    8
        call    other
        add     esp, 24
        ret

If the stack grows at numerically lower address why does pointer comparison reverses this?

4 Answers4

Related