In iterative singly-linked-list reversal, why must you save the next node before rewiring?

## The constraint that creates the whole problem A node in a singly linked list holds a value and exactly **one** outgoing link, pointing at its successor. There is no backward link. That single fact generates every rule in list reversal: the moment you overwrite a node's outgoing link, whatever it used to point at is reachable only if some *other* reference still names it. Picture a notification feed stored newest-first — the head is the most recent record, and each node links to the next-older one. Replaying it oldest-first means flipping the direction of every link, in place, without building a second feed. ## The four-step body The iterative walk keeps three references: - `prev` — head of the portion already reversed. It starts as null, because the original head becomes the new tail and must end up pointing at nothing. - `curr` — the node currently being flipped. - `nxt` — a temporary holding `curr`'s *original* successor. The body, in exactly this order: ``` nxt = curr.next // save the remainder curr.next = prev // flip this node's link prev = curr // extend the reversed prefix curr = nxt // step into the remainder ``` Only the first line is defensive; the other three are bookkeeping. Reordering any of them breaks the list. ## Trace the mistake, don't just name it Suppose the save is dropped and the body is `curr.next = prev; prev = curr; curr = curr.next`. Start with `prev = null`, `curr = head`. 1. `curr.next = prev` sets the head's link to null. The second record — and through it every older record — is now named by nothing. 2. `prev = curr`, so `prev` is the head. 3. `curr = curr.next` reads the link that was just overwritten, so `curr` becomes null. The loop condition fails and the routine returns a **one-node list**. The failure is silent: no error is raised, no crash, no cycle — the feed simply arrives with one record in it. Silent truncation is exactly why interviewers use this question; a candidate who narrates the trace above has shown they can hold two references in their head at once. A close cousin of the same mistake is advancing `prev` before saving: `prev = curr; nxt = curr.next; curr.next = prev` sets `curr.next = curr`, a **self-loop**. That failure is worse than truncation, because the next traversal of the feed never terminates. ## The degenerate cases fall out for free With the loop written as `while curr != null`, an empty list never enters the body and `prev` is returned still null — the correct answer. A single-node list enters once, sets that node's link to null (it already was null), and returns it unchanged. No guard clause is needed. Say this out loud at the whiteboard before you write the loop: stating the empty and single-node cases up front is a cheap, heavily rewarded habit, and candidates who add an `if head == null` guard usually add three more unnecessary guards after it. ## Why no second list is needed Reversal is often mis-answered as "walk the list pushing values onto a stack, then rebuild." That does work and it is still O(n) time, but it costs O(n) extra space and, in the value-copying form, produces different node objects — anything else holding a reference to a record now points into the old, half-dismantled structure. In-place link flipping keeps every node identity intact and uses O(1) auxiliary space. The three references do not grow with n; that is the entire space argument. One genuine subtlety: in-place reversal *invalidates* any reference someone else holds to the old head, because that node is now the tail. If a live consumer is walking the feed concurrently, reversing under it is not safe — but that is a coordination question, not a pointer question. ## Termination and what comes back The loop advances `curr` one node per iteration and never revisits a node, so it runs exactly n times and terminates when `curr` is null. At that point `prev` names the last node visited — the original tail — which is the head of the reversed list. Return `prev`. Returning `curr` returns null, one of the most common submitted bugs in this exercise. ## The doubly linked variant If each node also stores a backward link, reversal means swapping the two links of every node and then returning the old tail. The same discipline applies for the same reason: save what you are about to overwrite before you overwrite it.