So I don't really understand the whole concept of a stack and a buffer, I can kind of understand a buffer as it seems to just be memory that holds data temporarily before moving on, but stacks is a little bit harder to understand. Any help?
A stack is exactly as it sounds: a stack. Think of a stack of books, a stack of paper, whatever.
It is one of the foundations of how computer memory works. A computer memory (you can think of its RAM, but in reality its a bit more than just that) contains 4 main portions, when a program is operating:
Stack, Static, Heap, Code
Each portion are allocated a space. The stack is reserved for the program to use dynamically. This means that the stack tend to hold things like calculated data, that will eventually be turned over.
The stack grows as your program use more memory. The direction it grows is downwards for convenience purposes (you can look further into this). Like a stack of books, the first thing that gets on the stack will eventually be the last thing that comes out. This is because it grows by layering itself on top of itself, and like a stack of books, you cannot take out the bottom book without first removing the top books. This is all implemented so that the assembly programmer will have utmost control of his domain without accidentally jumping around and touching other people's code (which does happen, and is a security flaw ie buffer overflow)
Stack overflow happens when you've run out of stack space (and touch the Heap space).
It is one of the foundations of how computer memory works. A computer memory (you can think of its RAM, but in reality its a bit more than just that) contains 4 main portions, when a program is operating:
Stack, Static, Heap, Code
Each portion are allocated a space. The stack is reserved for the program to use dynamically. This means that the stack tend to hold things like calculated data, that will eventually be turned over.
The stack grows as your program use more memory. The direction it grows is downwards for convenience purposes (you can look further into this). Like a stack of books, the first thing that gets on the stack will eventually be the last thing that comes out. This is because it grows by layering itself on top of itself, and like a stack of books, you cannot take out the bottom book without first removing the top books. This is all implemented so that the assembly programmer will have utmost control of his domain without accidentally jumping around and touching other people's code (which does happen, and is a security flaw ie buffer overflow)
Stack overflow happens when you've run out of stack space (and touch the Heap space).
When I was referring to calculated data, I really meant anything and everything that a computer does.
Perhaps the following analogy will be slightly clearer.
You are the CPU. You can do loads of cool stuff like addition, multiplication, and arithmetic operations, stuff like that. You also happen to have 32 hands (registers).
You have a very long table in front of you. This table is your working memory. On the left is where the stack begins. Your instruction manual (Code) is on the right. Since the instruction manual doesn't change, you know precisely how long it is.
Following the Code is the static. This is the place you store data that you know will never change. Perhaps the name of your parents.
After the static, comes the Heap. But nvm, you wanted to know more about the stack. So here it goes.
with your 32 hands, you can do pretty much anything a modern computer can do. The only catch is this: You must know precisely where you are on the table at any point of time. Therefore, one of your hands (the stack pointer) will always point to the last pushed data on the table.
By referring to the instruction manual, you will know what to do at any point of time. Perhaps you will want to take the 3rd element to the left of where the stack pointer is pointing at, and multiply it with the last element you pushed on the stack. What you, as the CPU, do is you grab (copy) the data from the desired positions by counting them from the stack pointer. So now, two of your hands hold objects A and B, which you can use to multiply together to get object C.
Now say you want to keep object C on the table, so that in the future (according to the instruction sheet code-section) you can use it. You then put (push) object C from your hand onto the stack. The stack pointer moves down to make a little room for the object.
This is the stack "growing", and it grows as you calculate more data, according to what code you are given.
Now, what happens to the data that we no longer need? Say after a while, you are done with C. You cannot just leave C there lying on your table- it will collect dust and do exactly nothing! So what you can do is remove (pop) object C from the table. The stack pointer moves back left (or up), and from the coder's perspective, object C is no longer on the stack!
The stack is a method of manipulating memory on the computer so that we can run code on what amounts to bits of silicon and wire.
Perhaps the following analogy will be slightly clearer.
You are the CPU. You can do loads of cool stuff like addition, multiplication, and arithmetic operations, stuff like that. You also happen to have 32 hands (registers).
You have a very long table in front of you. This table is your working memory. On the left is where the stack begins. Your instruction manual (Code) is on the right. Since the instruction manual doesn't change, you know precisely how long it is.
Following the Code is the static. This is the place you store data that you know will never change. Perhaps the name of your parents.
After the static, comes the Heap. But nvm, you wanted to know more about the stack. So here it goes.
with your 32 hands, you can do pretty much anything a modern computer can do. The only catch is this: You must know precisely where you are on the table at any point of time. Therefore, one of your hands (the stack pointer) will always point to the last pushed data on the table.
By referring to the instruction manual, you will know what to do at any point of time. Perhaps you will want to take the 3rd element to the left of where the stack pointer is pointing at, and multiply it with the last element you pushed on the stack. What you, as the CPU, do is you grab (copy) the data from the desired positions by counting them from the stack pointer. So now, two of your hands hold objects A and B, which you can use to multiply together to get object C.
Now say you want to keep object C on the table, so that in the future (according to the instruction sheet code-section) you can use it. You then put (push) object C from your hand onto the stack. The stack pointer moves down to make a little room for the object.
This is the stack "growing", and it grows as you calculate more data, according to what code you are given.
Now, what happens to the data that we no longer need? Say after a while, you are done with C. You cannot just leave C there lying on your table- it will collect dust and do exactly nothing! So what you can do is remove (pop) object C from the table. The stack pointer moves back left (or up), and from the coder's perspective, object C is no longer on the stack!
The stack is a method of manipulating memory on the computer so that we can run code on what amounts to bits of silicon and wire.
Yes. At least, it could be, in the past.
In reality, modern day operating systems protect their memory spaces. This means that every application have their own "long table", and no one else (except the kernel) can touch it. You can break into the kernel of course, but that's a different ball game.
In the past, there was no real protection, and one can simply buffer-overflow into the other person's code space. Currently, the moment the stack grows too large, a stack overflow error will occur and the program usually crashes.
In reality, modern day operating systems protect their memory spaces. This means that every application have their own "long table", and no one else (except the kernel) can touch it. You can break into the kernel of course, but that's a different ball game.
In the past, there was no real protection, and one can simply buffer-overflow into the other person's code space. Currently, the moment the stack grows too large, a stack overflow error will occur and the program usually crashes.
Stack overflow refers specifically to the case when the execution stack grows beyond the memory that is reserved for it. For example, if you call a function which recursively calls itself without termination, you will cause a stack overflow as each function call creates a new stack frame and the stack will eventually consume more memory than is reserved for it.
Buffer overflow refers to any case in which a program writes beyond the end of the memory allocated for any buffer (including on the heap, not just on the stack). For example, if you write past the end of an array allocated from the heap, you've caused a buffer overflow.
Buffer overflow refers to any case in which a program writes beyond the end of the memory allocated for any buffer (including on the heap, not just on the stack). For example, if you write past the end of an array allocated from the heap, you've caused a buffer overflow.
25% off coupon: DemonForums
Users browsing: 2 Guest(s)