Talk:Stack overflow

message: ok, how is this for a compromise, we keep the existing article largely as it is (but including the sources I found in mine that are relevant to it) and place my article (minus the redundant parts) under the title of "Stack Buffer Overflow", then at the top of both articles we place the little "this article is about foo, to see the other topic, go to bar", that way we keep the article (both of them), and we avoid confusion from either side of this debate because both articles will provide a quick explanation that you might be looking in the wrong place, if so go the correct article...
If this proposal will work for you then I'll go ahead and merge in small extra part of my article that is relevant to the existing one and create a new article under the title of "stack buffer overflow" and put disambiguation linkage at the top of each article...is that compromise agreeable to you? --Michael Lynn 01:24, 11 August 2007 (UTC)
replies: text: No objections here, sounds like a good idea to me. -- taviso 15:14, 11 August 2007 (UTC)
replies: text: Ok then, I'll start making the edits and get it ready later today... --Michael Lynn 01:35, 12 August 2007 (UTC)
thread_title: Modified Proposal

message: Is StackOverflow.com popular enough that it should have an article? I've heard people ask what Stack Overflow is (and not talking about what this article is about). Once it has an article, I guess a link to the article from this page or a disambiguation page would make sense. --Ben Atkin (talk) 18:05, 28 August 2008 (UTC)
replies: text: You know, I think it is. Teemu Leisti (talk) 10:06, 6 June 2014 (UTC)
replies: text:  Oh, and I just noticed it has been done already:  Stack Overflow, also redirected to from Stack Overflow (website). Teemu Leisti (talk) 10:08, 6 June 2014 (UTC)
thread_title: Jeff Atwood, Joel Spolsky, and StackOverflow.com

message: I have changed the previous incorrect wording to something a bit more correct. The claim stacks have a limited amount of "memory" is obviously completely wrong. In modern high end CPUs such as x86_64, address space is reserved for the stack, not memory. Memory is allocated from the page pool as required.
Additionally the claim overflow occurs when the stack uses too much memory is logically absurd. If the address space is limited you cannot use more memory than the allocated address space on the stack: it is the attempt to do so, not the impossible actuality of doing so, which leads to the stack overflow condition. This is true whether or not the machine issues a page fault, or actually allows the user to exceed he bound (the excess past the end of the stack in this case is not "in" the stack so it cannot be said to contain that memory).
I changed the wording to specify overflow occurs when the stack pointer exceeds the stack bound, which is a limit on its address space, however this is not really satisfactory either. In particular the Intel i64 has two stacks, and any program written in, say, C, can create a stack data structure.
In principle stacks are unbounded, however in practice there are bounds even on user defined stacks, and I believe this article does, reasonably, attempt to describe machine stacks, not user defined data structures.  — Preceding unsigned comment added by Skaller (talk • contribs) 16:00, 29 May 2013 (UTC)
thread_title:  changed bad wording 

message: This section seems to suggest that a stack may be required to convert primitive recursion to a loop. It's my understanding that all primitive recursion can be converted to a loop without a stack. By my understanding, it's non-primitive recursion that would require a stack to be implemented into a loop. Is the article wrong or am I misinformed? If the article is correct, I would suggest further citations and notes be added. 68.117.55.155 (talk) 05:11, 25 September 2018 (UTC)
replies: text: The article is trying to say that it is necessary for this to be done due to finite memory, essentially. The example clarifies it a bit; the recursive implementation on the left in practice requires more memory than the loop implementation on the right, because of the way functions are implemented in most architectures. In practice this means that if you do recursion in C++ or a similar language using the example on the left, you're going to waste a lot of memory, because every time the function is called, space on the stack is reserved for the argument, a base pointer, a return pointer and the function's scope. Does that help? I'm not really sure how to modify the article to explain this better, though, and I don't have a reference on hand that I can add. Namnatulco (talk) 05:27, 25 September 2018 (UTC)
thread_title:  "Very deep recursion"