Why does an unanchored regular expression accept input that its author meant to reject?

## Searching and testing are different questions There are two questions you can ask with a pattern, and they have different answers: - **Does a match exist somewhere in this subject?** This is a search. It tries the leftmost position at which a match can begin, and everything outside the matched span is irrelevant. - **Does this whole subject match?** This is a full-subject test, where the match must cover every character. Most interfaces default to the first question, or offer both under names that are easy to confuse. That is the root of the classic validation bug: a pattern written as a description of a *whole* value is evaluated as a *search* for a fragment. `[0-9]{4}` is a perfectly good description of a four-digit code and a useless validator, because `abc1234def` contains a four-digit run. ## What an anchor actually is An anchor is a **zero-width assertion**: it tests a property of a position between characters and consumes nothing. - `^` asserts the position at the start of the subject (or, in line mode, the start of any line). - `$` asserts the position at the end of the subject (or, in line mode, the end of any line). - `\b` asserts a **word boundary**: one side is a word character and the other is not, counting the string edges as non-word. - Lookahead and lookbehind generalise this — they test whether a sub-pattern matches at the current position without moving it. Because anchors consume nothing, adding them never changes the text a group captures. They only remove candidate matches. `^[0-9]{4}$` has no match at all in `abc1234def`, which is exactly what the validator wanted. ## Why the failure is easy to miss 1. The pattern is tested against well-formed samples, where it matches and the span happens to be the whole value. 2. The first malformed value still matches, because the good part is a substring of it. 3. The bug surfaces later as data that never should have been stored, usually with junk on one side of a value that looks fine. The failure also survives review well, because the pattern *reads* like a description of the whole value. Only the evaluation is a search. ## Word boundaries are not spaces `\bcat\b` matching in `the cat sat` finds `cat`, and the spaces are **not** part of the match — the boundary asserts a position between a non-word character and a word character. That is why `\bcat\b` also matches in `(cat)` and at the very start or end of the subject, where there is no space at all. Candidates who think `\b` consumes a space are surprised when a replacement removes the surrounding punctuation, or when the match offsets are one character off from what they expected. ## The two anchors are not symmetric everywhere This is a place where conventions genuinely differ, and the difference bites validators: - Some conventions make `$` match not only at the very end of the subject but also immediately before a trailing line terminator, so a value with a newline glued to the end still passes `^[0-9]{4}$`. - Some offer a separate absolute end-of-input anchor with no such concession. - Line mode — where `^` and `$` match at every internal line boundary — is opt-in in some conventions and configured elsewhere in others. The portable habit is to state which behaviour you rely on rather than to assume it: if a trailing line terminator must be rejected, use an absolute end-of-input assertion where the convention offers one, or reject line terminators explicitly inside the pattern. ## A checklist for a pattern used as a validator 1. Decide whether you are searching or testing the whole value, and make the pattern say so rather than relying on the call. 2. Anchor both ends; one anchor alone still lets junk hang off the other side. 3. Ask what a line terminator inside or at the end of the value would do. 4. Check the empty subject: `^[0-9]*$` accepts it, `^[0-9]+$` does not, and that difference is usually the real requirement. | pattern | `1234` | `abc1234def` | `1234\n` | |---|---|---|---| | `[0-9]{4}` | accepted | accepted | accepted | | `^[0-9]{4}` | accepted | rejected | accepted | | `^[0-9]{4}$` | accepted | rejected | convention-dependent | The third column is the one that turns a description into a validator; the fourth is the one worth knowing about before it becomes a defect.