In a circular singly-linked list, why does walking until a NIL next reference never terminate?

## Where the termination condition comes from Every traversal needs a stopping rule. In a singly- or doubly-linked list the rule is handed to you by the layout: the last node's `next` field holds NIL, a value that is not a node, so `while curr != NIL` distinguishes "more list" from "end of list" without any extra state. The loop is so idiomatic that it gets written reflexively. A circular list is exactly the variant that deletes that guarantee. Its last node's `next` points back to the first node, and if it is circular *and* doubly-linked, the first node's `prev` points back to the last. The ring has no beginning and no end — only whichever node your handle happens to name. Run the reflexive loop over it and `curr` is never NIL, so the traversal cycles the ring forever, doing real work each time round: in a long-running process that is a hang and a growing output, not a crash, which makes it slower to diagnose than a null-reference fault would be. ## The three candidate conditions **Wrong: `while curr != NIL`.** Never fires. This is the bug. **Wrong: `while curr != start` as a pre-test loop.** Terminates instantly and visits nothing, because the loop begins with `curr == start`. This is the classic over-correction — the comparison is right, the loop shape is not. **Right: visit first, then test.** Two equivalent formulations: ``` repeat visit(curr) curr = curr.next until curr == start ``` or, if the loop must be pre-test, walk while `curr.next != start` and handle the last node after the loop. Both visit every node exactly once. ## The details that separate a correct answer from a nearly correct one **Guard the empty ring.** If the handle is NIL there is no starting node, and a do-while shape dereferences it before testing anything. The emptiness check belongs *before* the loop, not inside the condition. **Compare identity, not value.** In a turn-order ring for a four-player board game, two seats can easily carry the same stored value — the same team colour, the same score, the same NIL payload for an eliminated player. Terminating when the current node's *value* matches the start's value stops early and silently skips players. The test must be "is this the same node", not "does this look like the start". **Do not lean on a maintained count.** "Loop `size` times" reads clean and is genuinely used, but it converts a structural invariant into a bookkeeping one: a single insert or delete path that forgets to update `size` turns every traversal into either a short read or an over-run into already-visited nodes. Identity comparison cannot drift, because it reads the same references the traversal is already following. **Removal changes the ring's shape.** Two cases are easy to miss. Removing the node the handle names requires moving the handle to another node first, or every later operation starts from a node that has left the ring. Removing the *only* node — the one whose `next` is itself — must set the handle to NIL, because unlinking it leaves a one-node ring pointing at a departed node, which then traverses forever as a ghost list of one. ## Why choose a ring at all The turn-order case shows the payoff. Play advances forever and wraps: after the fourth seat comes the first. The alternative is a linear list plus an index that is reset when it runs off the end, which means every advance carries a bounds test and every piece of code that advances play must remember to write that test. The ring pushes the wrap into the structure — `curr = curr.next` is total, and there is no end to fall off. Add or eliminate a player and the ring stays correct with no index to fix up. The price is exactly the one this question is about: you have traded the free termination sentinel for an explicit stopping rule that every traversal must supply for itself. That is a fair trade when advancing is the common operation and full passes are rare, and a poor one when the code is dominated by scans that each have to re-derive where to stop. ## Interview shape Name the missing NIL first, then give the identity condition, then volunteer the loop-shape trap. Finishing with the empty-ring guard and the single-node removal case is what makes the answer read as lived rather than recited.