Using raw Node type for next causes infinite size error
Using references without lifetimes
Omitting Option for nullable next
3. Given the following Rust code to detect a circular linked list, what will be printed?
fn is_circular(head: &Option) -> bool {
let mut slow = head.as_ref();
let mut fast = head.as_ref();
while let (Some(s), Some(f)) = (slow, fast) {
fast = f.next.as_ref().and_then(|n| n.next.as_ref());
slow = s.next.as_ref();
if slow == fast {
return true;
}
}
false
}
// List: 1 -> 2 -> 3 -> 2 (loop back to node with value 2)
// Calling is_circular returns what?
medium
A. false
B. true
C. Compilation error
D. Infinite loop
Solution
Step 1: Understand Floyd's cycle detection
Two pointers move at different speeds; if they meet, list is circular.
Step 2: Analyze given list and code
List loops back from node 3 to node 2, so slow and fast pointers will meet, returning true.
Final Answer:
true -> Option B
Quick Check:
Floyd's algorithm detects loop = true [OK]
Hint: Floyd's cycle detection returns true if pointers meet [OK]
Common Mistakes:
Confusing pointer movement speeds
Not checking both pointers for null
Assuming no loop when pointers meet
4. Identify the bug in this Rust function that tries to detect a circular linked list:
fn has_cycle(head: &Option) -> bool {
let mut slow = head.as_ref();
let mut fast = head.as_ref();
while fast.is_some() && fast.unwrap().next.is_some() {
slow = slow.unwrap().next.as_ref();
fast = fast.unwrap().next.as_ref().unwrap().next.as_ref();
if slow == fast {
return true;
}
}
false
}
medium
A. Function always returns false due to wrong loop condition
B. Pointers move at the same speed, so no cycle detection
C. Using unwrap() without checking can cause panic if null
D. Missing return type causes compilation error
Solution
Step 1: Check unwrap usage safety
Using unwrap() without confirming Some can panic if null is encountered.
Step 2: Identify risk in loop
fast.unwrap().next.as_ref().unwrap() assumes next exists, which may not be true at list end.
Final Answer:
Using unwrap() without checking can cause panic if null -> Option C
Quick Check:
Unsafe unwrap causes panic [OK]
Hint: Avoid unwrap without checking Option first [OK]
Common Mistakes:
Ignoring unwrap panic risk
Assuming pointers move same speed
Not checking loop exit conditions
5. You have a linked list where the last node's next pointer is mistakenly set to itself, creating a single-node loop. How should you modify the Rust cycle detection function to correctly detect this case?
hard
A. Use a hash set to store visited nodes and detect repeats
B. Ignore cases where next points to itself, treat as non-circular
C. Only check if fast pointer reaches null to decide no cycle
D. Check if slow and fast pointers meet even if they start at the same node
Solution
Step 1: Understand single-node loop problem
If a node points to itself, Floyd's algorithm may detect cycle, but edge cases can be tricky.
Step 2: Use hash set for robust detection
Storing visited nodes in a hash set helps detect any repeated node, including self-loop cases.
Final Answer:
Use a hash set to store visited nodes and detect repeats -> Option A
Quick Check:
Hash set detects all cycles including self-loops [OK]
Hint: Use hash set to catch all loops including self-pointing nodes [OK]
Common Mistakes:
Assuming Floyd's algorithm covers all edge cases
Ignoring self-loop as cycle
Not handling single-node circular lists
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.