2

After reading the following question, I understand that there no such thing exist (at least not 'portable').

However I am starring at the following piece of code from mono code base, which return a pointer to the stack:

static void *
return_stack_ptr ()
{
    gpointer i;
    return &i;
}

I am surprised that the above code can even work on arch such as PowerPC, I would have assumed this would only work on x86 (and maybe only gcc).

Is this going to work on PowerPC ?

Community
  • 1
  • 1
malat
  • 12,152
  • 13
  • 89
  • 158
  • 1
    There is no portable function that could return a pointer to the stack in C. There are only degrees of unportability. – Antti Haapala -- Слава Україні Apr 07 '16 at 09:48
  • This kind of stuff is platform and compiler dependent. – Jabberwocky Apr 07 '16 at 09:54
  • The PowerPC ABI does have the notion of stack memory, but your compiler may choose to put variable `i` in another memory other than the stack. Nevertheless, I'd say it will work with any mainstream PowerPC compiler – atturri Apr 07 '16 at 10:02
  • @atturri: The compiler _will_ have to put the variable `i` somewhere in memory, if you (correctly) use its address. There's no choice. – MSalters Apr 07 '16 at 10:44
  • @MSalters: but it doesn't have to be on stack memory, does it? A fancy compiler could choose to use other memory areas for certain local variables. The question is about whether that pointer will look at the stack. – atturri Apr 07 '16 at 10:54
  • 1
    @atturri: "the stack" is an informal term anyway, for "the memory area where local variables are stored". By definition, `&i` points inside the stack. However, there is no guarantee that "the stack" is a contiguous memory area, or that `&i` is located at either end, or that you can do pointer arithmetic on `&i`. – MSalters Apr 07 '16 at 11:04
  • Mono must have tested this and found that it works the way they want on the compiler(s) they support building with. They use it in a garbage-collection function, to get `void* stackdata_end = return_stack_ptr ()`, which they then use as an arg to `memcpy`. I wouldn't have guessed this would be viable, but apparently it is. I think the key is that it's ok to copy a bit too much data, so the return value doesn't have to be exact, just something below the caller's stack frame. (And it's not `noinline`, so I guess copying all of `copy_stack_data`'s own stack frame isn't important.) – Peter Cordes Apr 07 '16 at 14:22

1 Answers1

4

The purpose of the stack is supporting function calls and local variables. If your system has a stack, it's going to use it, and allocate the local variable there. So it's very reasonable to assume that the address of the local variable points somewhere in the stack. This is not specific to x86 or gcc - it's a fairly general idea.

However, using a pointer to a variable that doesn't exist (i.e. after it goes out of scope) is Undefined Behavior. So this function cannot be guaranteed to do anything meaningful. In fact, a "clever" compiler could detect that your program uses undefined behavior, and replace your code by a no-op (and call it a "performance optimization").

Alternatively, a "wise" compiler could recognize that your function returns a pointer to the stack, and inline it by using a hardware stack pointer instead.

Neither option is guaranteed - this code is not portable.

anatolyg
  • 26,506
  • 9
  • 60
  • 134
  • 2
    Note that the mere act of _having_ a pointer that was once valid isn't UB by itself. This is just the normal state after `free(ptr)` returns, for instance. – MSalters Apr 07 '16 at 10:42