If you strip away all the complexity of a stack implementation, one piece of state remains absolutely essential: the top pointer. Without it, you have just an array—with it, you have a functional stack.

The top pointer is deceptively simple: it's just an integer. But this integer carries enormous responsibility:

• It determines where the next element will be placed
• It defines the boundary between "in the stack" and "outside the stack"
• It enables O(1) access to the current top element
• It provides the stack's size in constant time
• It indicates whether the stack is empty or full

Understanding top pointer management is not optional—it's the difference between a working stack and a collection of subtle bugs waiting to crash your program.

There are exactly two widely-used conventions for what the top pointer represents:

Convention A: Top points to the last filled index

In this model, top holds the index of the element currently at the top of the stack. The value of top directly answers the question: "Which array index contains the top element?"

Convention B: Top points to the next empty slot

In this model, top holds the index where the next element will be pushed. It answers the question: "Where should I put the next element?"

Both conventions are valid, widely used, and mathematically equivalent (they differ by exactly 1). However, they require different initialization and produce different implementations of push, pop, and other operations.

Let's examine each in complete detail.

In Convention A, the top pointer indicates where the current top element resides. This is sometimes called the "pointing-to" convention because top points to an actual element.

Initialization:

top = -1   // Empty stack has no elements, so top points "before" the array

Why -1? Because when the stack is empty, there is no valid element to point to. Using -1 (an invalid array index) signals this state clearly. When we push the first element, it will go to index 0, and top will become 0.

Visual representation of an empty stack:

top = -1
array: [ _ ][ _ ][ _ ][ _ ]
              (all slots empty)

After push(10):

top = 0
array: [10][ _ ][ _ ][ _ ]
        ↑
       top points here (index 0 contains top element)

After push(20):

top = 1
array: [10][20][ _ ][ _ ]
            ↑
           top points here

Step-by-step trace with Convention A:

Starting with top = -1 (empty stack):

1. push(10): top becomes 0 (via ++top), then array[0] = 10
2. push(20): top becomes 1 (via ++top), then array[1] = 20
3. push(30): top becomes 2 (via ++top), then array[2] = 30
4. peek(): returns array[2] = 30, top stays 2
5. pop(): returns array[2] = 30, then top becomes 1 (via top--)
6. pop(): returns array[1] = 20, then top becomes 0
7. pop(): returns array[0] = 10, then top becomes -1 (empty)
8. isEmpty(): returns top == -1 = true

Final state: top = -1, stack is empty again

This trace confirms the push and pop operations are correctly inverse: pushing three elements then popping three returns to the original state.

In Convention B, the top pointer indicates where the next element will be placed. This is sometimes called the "size" convention because top happens to equal the current size of the stack.

Initialization:

top = 0   // Empty stack, next element goes to index 0

Why 0? Because in an empty stack, the first push should place an element at index 0. The pointer is "ahead" of the filled portion.

Visual representation of an empty stack:

top = 0
array: [ _ ][ _ ][ _ ][ _ ]
        ↑
       next push goes here

After push(10):

top = 1
array: [10][ _ ][ _ ][ _ ]
            ↑
           next push goes here (index 1)

After push(20):

top = 2
array: [10][20][ _ ][ _ ]
                ↑
               next push goes here (index 2)

Step-by-step trace with Convention B:

Starting with top = 0 (empty stack):

1. push(10): array[0] = 10, then top becomes 1 (via top++)
2. push(20): array[1] = 20, then top becomes 2
3. push(30): array[2] = 30, then top becomes 3
4. peek(): returns array[top - 1] = array[2] = 30
5. pop(): top becomes 2 (via --top), then returns array[2] = 30
6. pop(): top becomes 1, then returns array[1] = 20
7. pop(): top becomes 0, then returns array[0] = 10
8. isEmpty(): returns top == 0 = true

Final state: top = 0, stack is empty again

Note the post-increment in push and pre-decrement in pop—the opposite order from Convention A.

Both conventions are mathematically equivalent—you can always convert between them by adding or subtracting 1. But there are subtle practical differences that might influence your choice:

Industry preference:

Convention B (top = next empty slot) is more common in production code and standard library implementations. Reasons include:

1. No negative indices—cleaner for bounds checking
2. Size equals top—fewer off-by-one bug opportunities
3. Aligns with array length semantics in most languages

However, many academic courses and textbooks use Convention A, so you'll likely encounter both. The key is consistency: pick one and use it throughout your codebase.

Proper initialization is the foundation of correct stack behavior. Let's examine common mistakes and how to avoid them:

Mistake 1: Wrong initial value for the convention

// WRONG: Using Convention A operations with Convention B initialization
int top = 0;  // Convention B
// ... later ...
push(x) { array[++top] = x; }  // Convention A operation!

Result: First push goes to index 1, leaving index 0 empty. The stack now has a "phantom slot" that was never filled.

Mistake 2: Forgetting to initialize

class Stack {
    int top;  // Uninitialized!
    int[] array = new int[10];
    
    void push(int x) {
        array[top++] = x;  // top contains garbage
    }
}

Result: top might be 0, or it might be 8,347,291. Undefined behavior.

Mistake 3: Initializing array but not top

In some languages, creating a new array might zero-initialize the contents, leading developers to assume top is also initialized. It's not—they're separate concerns.

The top pointer is the key to detecting the two critical boundary conditions: empty and full stacks.

Empty Stack Detection:

An empty stack is one where no elements have been pushed (or all pushed elements have been popped). The top pointer tells us this:

Full Stack Detection (fixed capacity):

A full stack is one where pushing another element would exceed the array's capacity:

Defensive checks before operations:

Every push and pop should include defensive checks:

// Convention B example
void push(int x) {
    if (top >= capacity) {
        throw new StackOverflowException();
    }
    array[top++] = x;
}

int pop() {
    if (top <= 0) {
        throw new EmptyStackException();
    }
    return array[--top];
}

int peek() {
    if (top <= 0) {
        throw new EmptyStackException();
    }
    return array[top - 1];
}

Note the use of top <= 0 rather than top == 0. This catches the case where top has somehow become negative (shouldn't happen, but defensive coding protects against bugs elsewhere).

Understanding common bugs helps you avoid them and debug them faster when they occur. Here's a catalog of the most frequent top pointer bugs:

Bug 1: Pre/Post-increment confusion

// Convention B intended
push(x) {
    this.array[++this.top] = x;  // Should be this.top++ for Convention B!
}

Symptom: First push goes to index 1, size() == top is wrong, peek() off by one.

Bug 2: Forgetting to check bounds

pop() {
    return this.array[--this.top];  // What if stack is empty?
}

Symptom: Returns garbage value when empty, or crashes with negative index.

Bug 3: Memory leak (reference types)

pop() {
    return this.array[--this.top];  // Element still referenced in array
}

Symptom: Popped objects never garbage collected. Fix: let x = array[--top]; array[top] = null; return x;

Bug 4: Concurrent modification

const stack = new Stack();
// Thread 1: push(10)
// Thread 2: push(20)
// Race condition on top, both threads might use same index

Symptom: Lost elements, corrupted state. Fix: Synchronization or atomic operations.

The top pointer is the soul of an array-based stack. Managing it correctly is the difference between a robust implementation and a bug factory. Let's consolidate what we've learned:

What's next:

With the top pointer thoroughly understood, we're ready to analyze the time complexity of push and pop operations. Spoiler: they're both O(1), but understanding why they're O(1) and what guarantees this performance is crucial. The next page dives into the complexity analysis.