Talk:Call stack

Incorrect statement

Article currently reads "The mixing of code (return addresses) and data (parameters, return values) in a call stack is a security risk, possibly exploitable through buffer overflows (in which article the risk and exploitation are explained)."

This is clearly an attempted reference to the exploit of buffer overflows by overwriting return addresses, allowing the exploit to snag control of the process. However, return addresses are not code, so to say "code (return addresses)" is incorrect. Return addresses are data about code, but this is (clearly) not the same thing. I don't think there's a way to fix this without significantly expanding the Security section, or referencing a buffer overflow article. It also might be worth noting that many current architectures don't allow execution of code on the stack (ref W^X, for example), making this even more obviously wrong.

Not true; executable stacks are a security risk exploitable by buffer overflow attacks. Consider the situation where the buffer overflow not only overwrites the return address, but pushes arbitrary code onto the stack. If the attacker can somehow figure out the current stack pointer, they can overwrite the return to return into their arbitrary code, which is arguably more dangerous than just returning into other code in the program. mkehrt (talk) 01:58, 31 October 2008 (UTC)

Good point about W^X. I added a mention of W^X to the article, and made sure the article no longer confuses "code" with "return addresses".

I also mentioned the attack mkehrt described, even though W^X makes it irrelevant.

Fixed. --DavidCary (talk) 18:51, 15 October 2014 (UTC)

Structure / Separate Stack Frame page ?

The "Structure" section is pretty good and comprehensive, it might make sense to consider putting the "stack frame"-related stuff on a separate "Stack Frame" page, what do you guys think?

Here are some additional pointers to help improve the "Stack Frame" related article:

• http://www.codeguru.com/cpp/misc/misc/stack/article.php/c3875/
• http://www.openasthra.com/cc-programming-concepts/frame-pointer-vs-stack-pointer/
• http://www.issociate.de/board/post/141099/Frame_pointer_Vs_Stack_Pointer.html
• http://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap
• http://stackoverflow.com/questions/525660/how-are-variables-on-the-stack-accessed
• http://stackoverflow.com/questions/429995/how-do-c-and-c-store-large-objects-on-the-stack
• http://stackoverflow.com/questions/579262/what-is-the-purpose-of-the-frame-pointer
• http://stackoverflow.com/questions/135262/how-to-preserve-stack-space-with-good-design

Return address alternatives

This article claims that "Using a stack to save the return address has important advantages over alternatives."

What are those alternatives?

Should we describe those alternatives in this article? If not, what is a more appropriate Wikipedia article(s) for describing those alternatives? --DavidCary (talk) 16:51, 15 October 2014 (UTC)

Alternatives that have been used include keeping the return address in a register. This is probably still being used on a few small embedded processors (which may have hardware support for say 8 registers for stacking return addresses, allowing a maximum nesting depth of eight). Another is saving the return address right next to the code of the called or calling routine. This was used in System/360 and earlier machines, as can be seen at the Hello World example in IBM Basic assembly language and successors#Examples. Doing that is neither reentrant nor allows recursion, and uses a writable area for code. The machine could have used a stack but IBM had an allergy to stacks (NIH; stacks were a Burroughs thing).

If this stuff belongs in WP, I'd say it would better be in "Calling convention" than here. --R. S. Shaw (talk) 23:10, 15 October 2014 (UTC)

Good point, R. S. Shaw. So I changed that sentence so this article now says "Using a stack to save the return address has important advantages over alternative calling conventions.".

Alas, the Wikipedia "calling convention" article currently only lists calling conventions that *do* use a stack to save the return address, so it currently *appears* that there isn't really any alternative, but that's more of a problem with the Wikipedia "calling convention" article. --DavidCary (talk) 15:00, 17 December 2014 (UTC)

Well, the Calling convention article is fine in that regard, here's a short quote from its lead section:

... return value is delivered from the callee back to the caller (on the stack, in a register, or within the heap)

Rest of the article also describes how processor registers can be used for that purpose, for example in different architectures. — Dsimic (talk | contribs) 19:23, 21 December 2014 (UTC)

Dear Dsimic, the "return address" that a caller somehow gives to a subroutine is different from any "return value" that a subroutine gives to a caller, right?

Yes, the "calling convention" article does a great job covering the many ways a "return value is delivered from the [subroutine] back to the caller".

However, in the current "calling convention" article, I only see one way a "return address" is delivered from the caller to the subroutine, even though this "call stack" article vaguely alludes to "alternatives" and R. S. Shaw points out one specific example of one alternative.

Perhaps talk:calling convention#Standard Entry and Exit sequences. would be a better place to continue this discussion? --DavidCary (talk) 19:58, 21 December 2014 (UTC)

It's about passing the return address implicitly to the subroutine on caller's behalf, not by the caller itself... Just think of the way high-level code is written: arguments are passed and return values are used, but the called subroutine comes back on its own. Thus, when a subroutine does its job, it knows where to return (that's where the return address kicks in), and it may return its result back to where it was called from; then, it's up to the caller to pop the return value off the stack, use the register value, etc.

Calling convention article discusses the ways return addresses are passed around, please have a look at Calling convention § MIPS, Calling convention § SPARC and Calling convention § ARM sections, for example. Went ahead and clarified that a bit in its lead section. — Dsimic (talk | contribs) 20:20, 21 December 2014 (UTC)

Wrong rendering

http://en.m.wikipedia.org/wiki/File:Call_stack_layout.svg has a strange piece of text on the left. 185.19.20.132 (talk) 09:53, 29 April 2015 (UTC)

Thanks, User:Offnfopt. 185.19.20.132 (talk) 16:46, 2 May 2015 (UTC)