Page actions
instrument / verified-clean
Regex Tester
The current ledger marks this instrument verified clean within the source-bound verification corpus.
Inspectable records
Ledger state
The current ledger marks this instrument verified clean within the source-bound verification corpus.
- Area
- Computing & Information
- Tranche
- tranche-4
- Evidence ID
- t4-184
- Ledger rows
- 1
No ledger note is attached.
Review findings
Core JavaScript regex testing is plausible, but the engine description, supported-flag scope, result API, error reporting, offset convention, and zero-length/global-match contract must be specified before the instrument can receive PASS.
Formula and scope findings
- "JS RegExp engine execution (NFA-based matching)" is not a precise or universally correct formula: JavaScript specifies RegExp matching semantics, while engines may use backtracking, hybrid, or other implementations; backreferences and lookarounds are not regular-language NFA operations.
- The supported flag list is incomplete for JavaScript semantics: it omits at least y (sticky), d (hasIndices), and v (Unicode sets, where supported).
- "Flags common errors" is underspecified: the spec does not define which syntax errors, unsupported flags, invalid escapes, or runtime behaviors must be detected and reported.
- Match-list behavior is ambiguous because JavaScript results differ among RegExp.prototype.exec, String.prototype.match, String.prototype.matchAll, and test; especially when g is present and for zero-length matches.
Unit assumptions
- There are no physical units.
- Match spans are assumed to use JavaScript UTF-16 code-unit offsets, with an exclusive end offset.
- The pattern syntax and flags are assumed to be JavaScript RegExp syntax, not PCRE, POSIX, ICU, or another flavor.
- With the u flag, matching is Unicode-aware, but JavaScript match indices still refer to UTF-16 code-unit positions.
- A global scan is assumed for match lists and counts; zero-length global matches are assumed to advance according to JavaScript RegExp rules.
Boundary hardening
Recorded hazards
- Division-by-zero is not applicable to this instrument, but an unguarded global zero-length pattern can cause an infinite loop if the implementation does not advance after an empty match.
- Invalid patterns or flags must produce a defined error result rather than a match list.
- UTF-16 offsets can split surrogate pairs when u is absent; the UI must label offsets as UTF-16 code units or explicitly convert them.
- Regexes with catastrophic backtracking can cause severe latency or denial of service; execution limits or cancellation are needed.
- Global matching state can persist in lastIndex when a reusable RegExp object is used, causing surprising results unless lastIndex is reset or managed explicitly.
- The native iOS note is correct: ICU NSRegularExpression is not behaviorally identical to JavaScript RegExp and must not be presented as an equivalent engine.
- The honest label should also disclose that JavaScript engine versions and supported flags can differ, and that match indices and zero-length behavior depend on the selected API contract.
Errata and corrections
No applied erratum is attached to this unique-name record.
Inspectable example
4 review vectors are recorded. One source-bound sample is shown below.
{
"inputs": {
"pattern": "cat",
"flags": "gi",
"test_string": "Cat scat"
},
"expected_outputs": {
"match_list": [
{
"text": "Cat",
"start": 0,
"end": 3,
"groups": []
},
{
"text": "cat",
"start": 5,
"end": 8,
"groups": []
}
],
"capture_groups": [
[],
[]
],
"highlighted_match_spans": [
[
0,
3
],
[
5,
8
]
],
"match_count": 2
},
"working": "1. UTF-16 positions in \"Cat scat\": C=0, a=1, t=2, space=3, s=4, c=5, a=6, t=7. 2. /cat/i matches \"Cat\" at start 0, exclusive end 0+3=3. 3. It also matches the final three characters of \"scat\": start 5, exclusive end 5+3=8. 4. Global matching returns 2 matches. 5. 2 matches × 0 capture groups gives capture arrays [], []."
}Related workflows
No source-defined multi-instrument workflow membership is recorded.
Sources and evidence
These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.
VERIFIED_LEDGER.json · VERIFIED_CLEANevidence-tranche4/tranche4-results.json