Two variants of the loop `while ((m = re.exec(s)) !== null) { … }` hang forever: one where `re` is `/\d/` and one where `re` is `/\d*/g`. Explain each hang, and say what you would write instead.

## Why an exec loop terminates at all `RegExp.prototype.exec(str)` on a regex carrying `g` or `y` does three things: it starts searching at the regex's `lastIndex`; on success it returns a match object and sets `lastIndex` to the index one past the end of the match; on failure it returns `null` and resets `lastIndex` to 0. The `while ((m = re.exec(s)) !== null)` idiom relies entirely on step two moving the cursor forward until step three fires. Remove that guarantee and the loop is infinite. ## Hang one: the missing flag ```js const re = /\d/; // no g let m; while ((m = re.exec('a1b2')) !== null) { console.log(m[0]); // '1' forever } ``` Without `g` (and without `y`), `exec` neither reads nor writes `lastIndex` — it always searches from index 0. So it returns the same first match on every iteration and never returns `null`. Notice the failure mode: the loop does not merely produce wrong results, it never ends, and it usually pegs a CPU rather than throwing anything you can catch. A closely related variant puts the literal in the condition itself: ```js while ((m = /\d/g.exec(s)) !== null) { … } ``` Here the `g` flag is present, but a regex **literal creates a fresh object each time it is evaluated**, so each iteration gets a brand-new regex with `lastIndex === 0`. Same hang, different cause. Hoist the regex into a variable outside the loop. ## Hang two: the zero-length match ```js const re = /\d*/g; // * allows the empty match let m; while ((m = re.exec('ab')) !== null) { console.log(JSON.stringify(m[0])); // '""' forever } ``` The flag is there and `exec` does write `lastIndex` — it sets it to the end index of the match. But `\d*` matches the empty string at position 0, so the start and end indices are both 0, and `lastIndex` is written back as 0. Nothing moved. Any pattern that can match nothing carries this risk: `\d*`, `\s*`, `(?:abc)?`, an alternation with an empty branch, or a pattern made of nothing but lookarounds and anchors. The standard guard is to bump the cursor yourself when the match is empty: ```js while ((m = re.exec(s)) !== null) { if (m[0] === '') re.lastIndex++; // or: if (m.index === re.lastIndex) // …handle m } ``` That is exactly what the spec's own `AdvanceStringIndex` step does inside the iterating APIs — and doing it by hand on a UTF-16 string means you can split a surrogate pair, another reason to prefer the built-in. ## What to write instead ```js for (const m of s.matchAll(re)) { console.log(m[0], m.index, m[1]); } ``` `String.prototype.matchAll` (ES2020) removes every failure mode above: - It **throws a `TypeError` if the regex is not global**, so the missing-flag hang becomes an immediate, obvious error instead of a spin. - It **advances past zero-length matches** internally, so the second hang cannot occur. - It **operates on a clone** of the regex seeded with your `lastIndex`, so it does not leave your (possibly module-level, possibly shared) regex object with a cursor parked mid-string. - It yields the **same rich match objects** `exec` produces — `m[0]`, the captures, `m.index`, `m.input` — so nothing is lost relative to the manual loop. - It is **lazy**, so `break` in the `for…of` stops the work, which a `str.match(re)` with `g` cannot do (and which would lose the captures and indices anyway). Spread it — `[...s.matchAll(re)]` — when you want an array, remembering that the iterator is one-shot. ## When a manual exec loop is still defensible Two cases. First, a **sticky** (`y`) tokeniser, where you deliberately drive `lastIndex` yourself: you set it to the current position, require the match to start exactly there, and advance by hand — the state is the point, not an accident. Second, a hot parsing loop where you have measured that allocating a match object per iteration matters. In both cases the code should say so, because a bare `while (exec)` reads as legacy. ## Diagnosing it in the wild A hung request with one core at 100% and no exception is the signature. Take a CPU profile or pause in the debugger: the stack sits inside the regex loop. Then check two things in order — does the regex have `g`, and can the pattern match the empty string? Note that this is a *loop* bug, distinct from a pathological-backtracking hang, where a single `exec` call never returns; in this one each `exec` call finishes instantly and it is the loop that never ends.