BST Inorder Successor in DSA Rust - Execution Trace

Concept Flow - BST Inorder Successor

Start at root node

↓

Find target node

↓

Does target have right child?

Yes→Go to right child

↓

Go left as far as possible

↓

Go up to ancestor where node is in left subtree

↓

Return found successor or None

Find the node, then if it has a right child, successor is leftmost node in right subtree; else go up to find ancestor where node is in left subtree.

Execution Sample

DSA Rust

fn inorder_successor(root: &Option<Box<TreeNode>>, p: &TreeNode) -> Option<i32> {
    // Find node p in BST and return its inorder successor value
}

This function finds the inorder successor of a given node p in a BST.

Execution Table

Step	Operation	Current Node	Pointer Changes	Visual State
1	Start at root to find node 5	10	current = 10	10 / \ 5 15
2	Go left since 5 < 10	5	current = 5	10 / \ 5 15
3	Node 5 found, check right child	5	right child = 7	10 / \ 5 15 \ 7
4	Go to right child 7	7	current = 7	10 / \ 5 15 \ 7
5	Go left as far as possible from 7	7	left child = None	10 / \ 5 15 \ 7
6	Leftmost node in right subtree is 7, successor found	7	successor = 7	10 / \ 5 15 \ 7
7	Return successor value 7	7	return 7	10 / \ 5 15 \ 7

💡 Successor found as leftmost node in right subtree of node 5

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	Final
current	root (10)	10	5	5	7	7	7	7
successor	None	None	None	None	None	None	7	7
right child	None	None	None	7	7	None	None	None

Key Moments - 3 Insights

Why do we go to the leftmost node in the right subtree?

Because the inorder successor is the smallest node greater than the target, which is the leftmost node in the right subtree (see execution_table step 5).

What if the node has no right child?

Then we must go up to ancestors to find the first ancestor where the node is in the left subtree (not shown in this example but important to understand).

Why do we stop going left when left child is None?

Because the leftmost node has no further left child, so it is the smallest node in that subtree (see execution_table step 5).

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of 'current' at step 4?

A 7

B 10

C 5

D 15

💡 Hint

Check the 'current' column in execution_table row for step 4.

At which step does the algorithm find the successor node?

A Step 3

B Step 6

C Step 5

D Step 7

💡 Hint

Look for the step where 'successor' variable is assigned in variable_tracker and execution_table.

If node 5 had no right child, what would the algorithm do next?

A Return None immediately

B Go to left child of node 5

C Go up to ancestors to find a node where current node is in left subtree

D Go to right child of root

💡 Hint

Refer to concept_flow where no right child leads to going up to ancestors.

Concept Snapshot

BST Inorder Successor:
- Find target node in BST
- If node has right child: successor = leftmost node in right subtree
- Else: go up to ancestor where node is in left subtree
- Return successor or None if no successor
- Used in BST traversal and deletion

Full Transcript

To find the inorder successor of a node in a BST, start at the root and find the target node. If the node has a right child, the successor is the leftmost node in that right subtree. If no right child exists, move up the tree to find the first ancestor where the node lies in the left subtree. This process ensures finding the next larger node in sorted order. The execution table shows step-by-step traversal from root to target, then to the successor node. Variables track current node and successor during traversal. Key moments clarify why we go leftmost in right subtree and what to do if no right child exists.

Practice

1. What is the inorder successor of a node in a Binary Search Tree (BST)?

easy

A. The node with the smallest key greater than the given node's key

B. The node with the largest key smaller than the given node's key

C. The left child of the given node

D. The right child of the given node

Solution

1. Step 1: Understand inorder traversal order

   Inorder traversal visits nodes in ascending order of their keys in a BST.

2. Step 2: Define inorder successor

   The inorder successor of a node is the next node visited after it in inorder traversal, which means the smallest node with a key greater than the current node.

3. Final Answer:

   The node with the smallest key greater than the given node's key -> Option A

4. Quick Check:

   Inorder successor = next bigger node [OK]

Hint: Inorder successor is next bigger node in sorted order [OK]

Common Mistakes:

• Confusing successor with predecessor
• Thinking successor is always right child
• Ignoring BST property in definition

2. Which Rust function signature correctly represents a method to find the inorder successor of a BST node?

easy

A. fn inorder_successor(root: &Option, p: &TreeNode) -> Option<&TreeNode>

B. fn inorder_successor(root: TreeNode, p: TreeNode) -> TreeNode

C. fn inorder_successor(root: &mut TreeNode, p: &mut TreeNode) -> TreeNode

D. fn inorder_successor(root: Option<TreeNode>, p: Option<TreeNode>) -> Option<TreeNode>

Solution

1. Step 1: Understand Rust ownership and references

   BST nodes are usually wrapped in Option to allow null and heap allocation. Passing references avoids ownership transfer.

2. Step 2: Analyze function signature correctness

   Option<&TreeNode> as return type allows returning a reference to a node or None. Input parameters as references to avoid moving ownership.

3. Final Answer:

   fn inorder_successor(root: &Option, p: &TreeNode) -> Option<&TreeNode> -> Option A

4. Quick Check:

   Use references and Option for safe BST traversal [OK]

Hint: Use references and Option types for BST nodes in Rust [OK]

Common Mistakes:

• Passing nodes by value causing ownership errors
• Returning owned nodes instead of references
• Using mutable references unnecessarily

3. Given the following Rust code snippet for finding the inorder successor, what will be printed?

struct TreeNode {
    val: i32,
    left: Option,
    right: Option,
}

fn inorder_successor(root: &Option, p_val: i32) -> Option<i32> {
    let mut successor = None;
    let mut current = root;
    while let Some(node) = current {
        if p_val < node.val {
            successor = Some(node.val);
            current = &node.left;
        } else {
            current = &node.right;
        }
    }
    successor
}

fn main() {
    let root = Some(Box::new(TreeNode {
        val: 20,
        left: Some(Box::new(TreeNode {
            val: 10,
            left: None,
            right: Some(Box::new(TreeNode {
                val: 15,
                left: None,
                right: None,
            })),
        })),
        right: Some(Box::new(TreeNode {
            val: 30,
            left: None,
            right: None,
        })),
    }));
    let result = inorder_successor(&root, 15);
    println!("{:?}", result);
}

medium

A. None

B. Some(20)

C. Some(15)

D. Some(30)

Solution

1. Step 1: Trace the search for successor of node with value 15

   Start at root (20). Since 15 < 20, successor = 20, move left to node 10. 15 > 10, move right to node 15.

2. Step 2: Continue traversal and finalize successor

   At node 15, 15 == 15, move right which is None. Loop ends. Last successor recorded is 20.

3. Final Answer:

   Some(20) -> Option B

4. Quick Check:

   Next bigger than 15 is 20 [OK]

Hint: Successor is smallest bigger node found going left [OK]

Common Mistakes:

• Returning the node itself as successor
• Confusing left and right subtree traversal
• Not updating successor when moving left

4. The following Rust function aims to find the inorder successor of a node in a BST but has a bug. What is the bug?

fn inorder_successor(root: &Option, p_val: i32) -> Option<i32> {
    let mut successor = None;
    let mut current = root;
    while let Some(node) = current {
        if p_val <= node.val {
            successor = Some(node.val);
            current = &node.left;
        } else {
            current = &node.right;
        }
    }
    successor
}

medium

A. Not handling None case for root

B. Function returns value instead of reference

C. Successor should be updated only when p_val > node.val

D. Using <= instead of < causes incorrect successor when p_val equals node.val

Solution

1. Step 1: Analyze condition p_val <= node.val

   Using <= means successor updates even when p_val equals node.val, which incorrectly sets successor to the node itself.

2. Step 2: Correct condition for successor update

   Successor should update only when p_val < node.val to find the next bigger node, not the node itself.

3. Final Answer:

   Using <= instead of < causes incorrect successor when p_val equals node.val -> Option D

4. Quick Check:

   Use < for successor update, not <= [OK]

Hint: Use strict less than (<) to avoid self as successor [OK]

Common Mistakes:

• Confusing < and <= in comparisons
• Ignoring edge case when p_val equals node.val
• Not testing with equal values

5. You have a BST where each node has a parent pointer in addition to left and right children. How can you find the inorder successor of a given node p efficiently using this extra pointer?

hard

A. Successor is always the right child of p

B. Always go to the root and perform inorder traversal to find successor

C. If p has right child, successor is leftmost node in right subtree; else go up using parent until node is left child

D. Use a stack to store nodes and pop until successor is found

Solution

1. Step 1: Check if node has right subtree

   If p has a right child, the successor is the leftmost node in that right subtree.

2. Step 2: If no right child, use parent pointer

   Move up the tree using parent pointers until you find a node which is the left child of its parent; that parent is the successor.

3. Final Answer:

   If p has right child, successor is leftmost node in right subtree; else go up using parent until node is left child -> Option C

4. Quick Check:

   Use right subtree or climb parents to find successor [OK]

Hint: Use parent pointer to climb up when no right child [OK]

Common Mistakes:

• Ignoring parent pointer advantage
• Assuming successor is always right child
• Performing full traversal unnecessarily