How can a stack underflow happen in C++?

What is a simple example in C++ that causes a stack underflow in the case of invoking and returning from method calls?

I am familiar with the calling convention, i.e thiscall, stdcall and the cdecl and way they would clean the stack. Wouldn't a stack underflow automatically be taken care of by the code generated by the compiler?

What are the situations that can开发者_如何学Go get me into trouble with stack underflow?

The only way I can see this actually happening would be if you declared a function to use the stdcall (or any other calling convention that specifies the callee clean the stack) and then invoke the function through a function pointer that was specified as a cdecl (or any other calling convention where the stack is cleaned by the caller). If you do that, the called function will pop the stack before returning and then the caller would also pop the stack leading to underflow and terrible things.

In the specific case of member functions, the calling convention is usually referred to as thiscall and whether the caller or the callee cleans the stack depends on the compiler.

See here for details of calling conventions.

I am not sure if you are talking of the data structure stack and the underflow problem in it or something else. As far as the stack(data structure) underflow problem is concerned here is a explanation.

stack is a last in, first out (LIFO) abstract data type and data structure. A stack can have any abstract data type as an element, but is characterized by only three fundamental operations: push, pop and stack top.

The push operation adds a new item to the top of the stack, or initializes the stack if it is empty. If the stack is full and does not contain enough space to accept the given item, the stack is then considered to be in an overflow state. The pop operation removes an item from the top of the stack.

A pop either reveals previously concealed items, or results in an empty stack, but if the stack is empty then it goes into underflow state (It means no items are present in stack to be removed).

The stack top operation gets the data from the top-most position and returns it to the user without deleting it. The same underflow state can also occur in stack top operation if stack is empty.

Consider a stack implementation example:

template <class Item> class Stack 
{
public:
    bool isEmpty() const;
    size_t size() const;
    Item pop();
    void push(const Item& it);
private:

};

Now consider the following operations being performed on this stack.

C++ command                      resulting stack
------------------------------------------------
Stack<int> S;
                                  _____ (empty stack of ints)



S.push(7);                            
                                  | 7 |  <-- top
                                  -----

S.push(2);                            
                                  | 2 |  <-- top 
                                  | 7 |
                                  -----

S.push(73);                           
                                  |73 |  <-- top 
                                  | 2 |
                                  | 7 |
                                  -----

S.pop();                           
                                  | 2 |  <-- top
                                  | 7 |                    -----
S.pop();      
                                  -----
S.pop();                           
                                  | 7 |  <-- top
                                  -----
S.pop();                           
                                  -----  (empty)

S.pop();                           
                    ERROR "stack underflow"

Normally this would be taken care of by the compiler. In reality, the only way I can think of that you could accidentally cause a stack underflow would be by calling a method implemented with one calling convention as if it was using another calling convention.

If you are ever in a position where a call-stack underflow could happen, chances are your program is going to die a violent death before it happens. At least, if I understand the way function calls work is accurate.

Basically, the only way for it to happen is if you call a function where the callee cleans up the stack, and it pops off too many values... if the caller believes a function accepts two parameters, but the callee actually takes three, this might happen. A variant would be a function where the callee cleans up the stack, and then the caller cleans up the stack again, as might happen if you get your calling convention wrong. In both situations, you will probably get a problem when you go to link and the mangled names are wrong, but perhaps you just get really unlucky.

Either way, the important thing is that after the function call, the stack is one or more bytes shorter than it is supposed to be. Theoretically the program will then continue on, popping the correct amount of data off, but remaining one or more bytes short of what is expected. Eventually, there is no more data to pop off, and you have a stack underflow.

However, when refering to the stack, addresses are relative to the top. So the compiler will look for a particular object at [top of stack + 3] if it is three bytes from the top of the stack. It will still do that if the stack ends up shorter than expected, and look for that object in the wrong location. Assuming that object is even still there... it might have accidently gotten popped off already. When you get to the end of whatever function you are in, it might not be able to find the correct return address for this same reason, but even if it does, having all of your objects suddenly corrupted is a pretty dire situation to be in.

Caveat: this is all based on the assumption that modern systems behave the same as the old microcontrollers I used to work on a decade ago. Maybe they're smarter than that now.