| <!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><meta http-equiv="X-UA-Compatible" content="IE=edge"><meta name="viewport" content="width=device-width, initial-scale=1.0"><meta name="generator" content="Asciidoctor 2.0.26"><meta name="description" content="Compatibility with Perl"><title>pcre2compat(3)</title><link rel="stylesheet" href="./css/document.css"><link rel="stylesheet" href="./css/standalone.css"><meta name="color-scheme" content="light dark"><meta name="theme-color" media="(prefers-color-scheme: light)" content="#0085cc"><meta name="theme-color" media="(prefers-color-scheme: dark)" content="#33b8ff"></head><body class="manpage offline-manual"><header class="offline-nav"><nav><a class="offline-index" href="./index.html">Index</a><a class="offline-home" href="https://www.pcre2.org/"><span aria-hidden="true">🌐︎</span> PCRE2 homepage</a></nav></header><main class="document-page"><header class="document-title"><h1>pcre2compat(3)</h1><p class="document-meta">PCRE2 10.50-DEV manual; updated <time datetime="2025-06-02">2 Jun 2025</time></p></header><div class="document-layout"><article class="prose" id="content"><section class="doc-section level-1"><h2 id="_differences_between_pcre2_and_perl">Differences between PCRE2 and Perl</h2><p>This document describes some of the known differences in the ways that PCRE2 | |
| and Perl handle regular expressions. The differences described here are with | |
| respect to Perl version 5.38.0, but as both Perl and PCRE2 are continually | |
| changing, the information may at times be out of date.</p> | |
| <ul class="spaced"><li>When <code class="constant pcre2-api rouge"><span class="no">PCRE2_DOTALL</span></code> (equivalent to Perl’s <code class="regex rouge"><span class="pcre2-semantic">/s</span></code> qualifier) is not set, the | |
| behaviour of the <code class="regex rouge"><span class="pcre2-semantic">.</span></code> metacharacter differs from Perl. In PCRE2, <code class="regex rouge"><span class="pcre2-semantic">.</span></code> matches the | |
| next character unless it is the start of a newline sequence. This means that, | |
| if the newline setting is CR, CRLF, or NUL, <code class="regex rouge"><span class="pcre2-semantic">.</span></code> will match the code point LF | |
| (<span class="character-info" title="" tabindex="0" aria-describedby="pcre2-character-1"><code class="character pcre2-api rouge"><span class="sc">0x0A</span></code><span class="character-card" id="pcre2-character-1" role="tooltip" aria-label="LINE FEED (U+000A)" aria-hidden="true" data-pagefind-ignore=""><span class="character-glyph" data-character=""></span><span class="character-name" data-character-name="LINE FEED"></span><span class="character-codepoint" data-codepoint="U+000A"></span></span></span>) in ASCII/Unicode environments, and NL (either <span class="character-info" title="" tabindex="0" aria-describedby="pcre2-character-2"><code class="character pcre2-api rouge"><span class="sc">0x15</span></code><span class="character-card" id="pcre2-character-2" role="tooltip" aria-label="NEGATIVE ACKNOWLEDGE (U+0015)" aria-hidden="true" data-pagefind-ignore=""><span class="character-glyph" data-character=""></span><span class="character-name" data-character-name="NEGATIVE ACKNOWLEDGE"></span><span class="character-codepoint" data-codepoint="U+0015"></span></span></span> or <span class="character-info" title="" tabindex="0" aria-describedby="pcre2-character-3"><code class="character pcre2-api rouge"><span class="sc">0x25</span></code><span class="character-card" id="pcre2-character-3" role="tooltip" aria-label="PERCENT SIGN (U+0025)" aria-hidden="true" data-pagefind-ignore=""><span class="character-glyph" data-character="%"></span><span class="character-name" data-character-name="PERCENT SIGN"></span><span class="character-codepoint" data-codepoint="U+0025"></span></span></span>) when using | |
| EBCDIC. In Perl, <code class="regex rouge"><span class="pcre2-semantic">.</span></code> appears never to match LF, even when <span class="character-info" title="" tabindex="0" aria-describedby="pcre2-character-4"><code class="character pcre2-api rouge"><span class="sc">0x0A</span></code><span class="character-card" id="pcre2-character-4" role="tooltip" aria-label="LINE FEED (U+000A)" aria-hidden="true" data-pagefind-ignore=""><span class="character-glyph" data-character=""></span><span class="character-name" data-character-name="LINE FEED"></span><span class="character-codepoint" data-codepoint="U+000A"></span></span></span> is not a newline | |
| indicator.</li><li>PCRE2 has only a subset of Perl’s Unicode support. Details of what it does | |
| have are given in the | |
| <a href="./pcre2unicode.html"><code>pcre2unicode</code></a> | |
| page.</li><li>Like Perl, PCRE2 allows repeat quantifiers on parenthesized assertions, but | |
| they do not mean what you might think. For example, <code class="regex rouge"><span class="pcre2-semantic">(?!a){3}</span></code> does not assert | |
| that the next three characters are not <code class="subject rouge"><span class="pcre2-semantic">a</span></code>. It just asserts that the next | |
| character is not <code class="subject rouge"><span class="pcre2-semantic">a</span></code> three times (in principle; PCRE2 optimizes this to run the | |
| assertion just once). Perl allows some repeat quantifiers on other assertions, | |
| for example, <code class="regex rouge"><span class="pcre2-semantic">\b*</span></code> , but these do not seem to have any use. PCRE2 does not allow | |
| any kind of quantifier on non-lookaround assertions.</li><li>If a braced quantifier such as <code class="regex rouge"><span class="pcre2-semantic">{1,2}</span></code> appears where there is nothing to | |
| repeat (for example, at the start of a branch), PCRE2 raises an error whereas | |
| Perl treats the quantifier characters as literal. When a braced quantifier | |
| <code class="regex rouge"><span class="pcre2-semantic">(...){<em>min</em>,<em>max</em>}</span></code> has <em>min</em> > <em>max</em>, Perl treats it as an item which fails to match | |
| any portion of the subject (as no number of repetitions can meet the | |
| condition), and additionally issues a warning when in warning mode. PCRE2 has | |
| no warning features, so it gives an error in this case.</li><li>Capture groups that occur inside negative lookaround assertions are counted, | |
| but their entries in the offsets vector are set only when a negative assertion | |
| is a condition that has a matching branch (that is, the condition is false). | |
| Perl may set such capture groups in other circumstances.</li><li>The following Perl escape sequences are not supported: <code class="regex rouge"><span class="pcre2-semantic">\F</span></code>, <code class="regex rouge"><span class="pcre2-semantic">\l</span></code>, <code class="regex rouge"><span class="pcre2-semantic">\L</span></code>, <code class="regex rouge"><span class="pcre2-semantic">\u</span></code>, | |
| <code class="regex rouge"><span class="pcre2-semantic">\U</span></code>, and <code class="regex rouge"><span class="pcre2-semantic">\N</span></code> when followed by a character name. <code class="regex rouge"><span class="pcre2-semantic">\N</span></code> on its own, matching a | |
| non-newline character, and <code class="regex rouge"><span class="pcre2-semantic">\N{U+<em>dd...</em>}</span></code>, matching a Unicode code point, are | |
| supported. The escapes that modify the case of following letters are | |
| implemented by Perl’s general string-handling and are not part of its pattern | |
| matching engine. If any of these are encountered by PCRE2, an error is | |
| generated by default. However, if either of the <code class="constant pcre2-api rouge"><span class="no">PCRE2_ALT_BSUX</span></code> or | |
| <code class="constant pcre2-api rouge"><span class="no">PCRE2_EXTRA_ALT_BSUX</span></code> options is set, <code class="regex rouge"><span class="pcre2-semantic">\U</span></code> and <code class="regex rouge"><span class="pcre2-semantic">\u</span></code> are interpreted as ECMAScript | |
| interprets them.</li><li>The Perl escape sequences <code class="regex rouge"><span class="pcre2-semantic">\p</span></code>, <code class="regex rouge"><span class="pcre2-semantic">\P</span></code>, and <code class="regex rouge"><span class="pcre2-semantic">\X</span></code> are supported only if PCRE2 is | |
| built with Unicode support (the default). The properties that can be tested | |
| with <code class="regex rouge"><span class="pcre2-semantic">\p</span></code> and <code class="regex rouge"><span class="pcre2-semantic">\P</span></code> are limited to the general category properties such as | |
| <code class="regex rouge"><span class="pcre2-semantic">Lu</span></code> and <code class="regex rouge"><span class="pcre2-semantic">Nd</span></code>, the derived properties <code class="regex rouge"><span class="pcre2-semantic">Any</span></code> and <code class="regex rouge"><span class="pcre2-semantic">Lc</span></code> | |
| (synonym <code class="regex rouge"><span class="pcre2-semantic">L&</span></code>), script names such as <code class="regex rouge"><span class="pcre2-semantic">Greek</span></code> or <code class="regex rouge"><span class="pcre2-semantic">Han</span></code>, | |
| <code class="regex rouge"><span class="pcre2-semantic">Bidi_Class</span></code>, <code class="regex rouge"><span class="pcre2-semantic">Bidi_Control</span></code>, and a few binary properties. Both PCRE2 and | |
| Perl support the <code class="regex rouge"><span class="pcre2-semantic">Cs</span></code> (surrogate) property, but in PCRE2 its use is limited. See | |
| the | |
| <a href="./pcre2pattern.html"><code>pcre2pattern</code></a> | |
| documentation for details. The long synonyms for property names that Perl | |
| supports (such as <code class="regex rouge"><span class="pcre2-semantic">\p{Letter}</span></code>) are not supported by PCRE2, nor is it permitted | |
| to prefix any of these properties with <code class="regex rouge"><span class="pcre2-semantic">Is</span></code>.</li><li><p>PCRE2 supports the <code class="regex rouge"><span class="pcre2-semantic">\Q...\E</span></code> escape for quoting substrings. Characters | |
| in between are treated as literals. However, this is slightly different from | |
| Perl in that <code class="regex rouge"><span class="pcre2-semantic">$</span></code> and <code class="regex rouge"><span class="pcre2-semantic">@</span></code> are also handled as literals inside the quotes. In Perl, | |
| they cause variable interpolation (PCRE2 does not have variables). Also, Perl | |
| does "double-quotish backslash interpolation" on any backslashes between <code class="regex rouge"><span class="pcre2-semantic">\Q</span></code> | |
| and <code class="regex rouge"><span class="pcre2-semantic">\E</span></code> which, its documentation says, "may lead to confusing results". PCRE2 | |
| treats a backslash between <code class="regex rouge"><span class="pcre2-semantic">\Q</span></code> and <code class="regex rouge"><span class="pcre2-semantic">\E</span></code> just like any other character. Note the | |
| following examples:</p><div class="table-block"><table class="frame-all grid-all stretch"><colgroup><col style="width: 25%;"><col style="width: 25%;"><col style="width: 50%;"></colgroup><thead><tr><th class="halign-left valign-top">Pattern</th><th class="halign-left valign-top">PCRE2 matches</th><th class="halign-left valign-top">Perl matches</th></tr></thead><tbody><tr><td class="halign-left valign-top"><code class="regex rouge"><span class="pcre2-semantic">\Qabc$xyz\E</span></code></td><td class="halign-left valign-top"><code class="subject rouge"><span class="pcre2-semantic">abc$xyz</span></code></td><td class="halign-left valign-top"><code class="subject rouge"><span class="pcre2-semantic">abc</span></code> followed by the contents of <code>$xyz</code></td></tr><tr><td class="halign-left valign-top"><code class="regex rouge"><span class="pcre2-semantic">\Qabc\$xyz\E</span></code></td><td class="halign-left valign-top"><code class="subject rouge"><span class="pcre2-semantic">abc\$xyz</span></code></td><td class="halign-left valign-top"><code class="subject rouge"><span class="pcre2-semantic">abc\$xyz</span></code></td></tr><tr><td class="halign-left valign-top"><code class="regex rouge"><span class="pcre2-semantic">\Qabc\E\$\Qxyz\E</span></code></td><td class="halign-left valign-top"><code class="subject rouge"><span class="pcre2-semantic">abc$xyz</span></code></td><td class="halign-left valign-top"><code class="subject rouge"><span class="pcre2-semantic">abc$xyz</span></code></td></tr><tr><td class="halign-left valign-top"><code class="regex rouge"><span class="pcre2-semantic">\QA\B\E</span></code></td><td class="halign-left valign-top"><code class="subject rouge"><span class="pcre2-semantic">A\B</span></code></td><td class="halign-left valign-top"><code class="subject rouge"><span class="pcre2-semantic">A\B</span></code></td></tr><tr><td class="halign-left valign-top"><code class="regex rouge"><span class="pcre2-semantic">\Q\\E</span></code></td><td class="halign-left valign-top"><code class="subject rouge"><span class="pcre2-semantic">\</span></code></td><td class="halign-left valign-top"><code class="subject rouge"><span class="pcre2-semantic">\\E</span></code></td></tr></tbody></table></div> | |
| <p>The <code class="regex rouge"><span class="pcre2-semantic">\Q...\E</span></code> sequence is recognized both inside and outside character classes | |
| by both PCRE2 and Perl. Another difference from Perl is that any appearance of | |
| <code class="regex rouge"><span class="pcre2-semantic">\Q</span></code> or <code class="regex rouge"><span class="pcre2-semantic">\E</span></code> inside what might otherwise be a quantifier causes PCRE2 not to | |
| recognize the sequence as a quantifier. Perl recognizes a quantifier if | |
| (redundantly) either of the numbers is inside <code class="regex rouge"><span class="pcre2-semantic">\Q...\E</span></code>, but not if the | |
| separating comma is. When not recognized as a quantifier a sequence such as | |
| <code class="regex rouge"><span class="pcre2-semantic">{\Q1\E,2}</span></code> is treated as the literal string <code class="subject rouge"><span class="pcre2-semantic">{1,2}</span></code>.</p></li><li>Fairly obviously, PCRE2 does not support the <code class="regex rouge"><span class="pcre2-semantic">(?{<em>code</em>})</span></code> and | |
| <code class="regex rouge"><span class="pcre2-semantic">(??{<em>code</em>})</span></code> | |
| constructions. However, PCRE2 does have a "callout" feature, which allows an | |
| external function to be called during pattern matching. See the | |
| <a href="./pcre2callout.html"><code>pcre2callout</code></a> | |
| documentation for details.</li><li>Subroutine calls (whether recursive or not) were treated as atomic groups | |
| up to PCRE2 release 10.23, but from release 10.30 this changed, and | |
| backtracking into subroutine calls is now supported, as in Perl.</li><li>In PCRE2, if any of the backtracking control verbs are used in a group that | |
| is called as a subroutine (whether or not recursively), their effect is | |
| confined to that group; it does not extend to the surrounding pattern. This is | |
| not always the case in Perl. In particular, if <code class="regex rouge"><span class="pcre2-semantic">(*THEN)</span></code> is present in a group | |
| that is called as a subroutine, its action is limited to that group, even if | |
| the group does not contain any <code class="regex rouge"><span class="pcre2-semantic">|</span></code> characters. Note that such groups are | |
| processed as anchored at the point where they are tested. PCRE2 also confines | |
| all control verbs within atomic assertions, again including <code class="regex rouge"><span class="pcre2-semantic">(*THEN)</span></code> in | |
| assertions with only one branch.</li><li>If a pattern contains more than one backtracking control verb, the first | |
| one that is backtracked onto acts. For example, in the pattern | |
| <code class="regex rouge"><span class="pcre2-semantic">A(*COMMIT)B(*PRUNE)C</span></code> a failure in <code class="regex rouge"><span class="pcre2-semantic">B</span></code> triggers <code class="regex rouge"><span class="pcre2-semantic">(*COMMIT)</span></code>, but a failure in <code class="regex rouge"><span class="pcre2-semantic">C</span></code> | |
| triggers <code class="regex rouge"><span class="pcre2-semantic">(*PRUNE)</span></code>. Perl’s behaviour is more complex; in many cases it is the | |
| same as PCRE2, but there are cases where it differs.</li><li>There are some differences that are concerned with the settings of captured | |
| strings when part of a pattern is repeated. For example, matching <code class="subject rouge"><span class="pcre2-semantic">aba</span></code> against | |
| the pattern <code class="regex rouge"><span class="pcre2-semantic">^(a(b)?)+$</span></code> in Perl leaves <code class="regex rouge"><span class="pcre2-semantic">$2</span></code> unset, but in PCRE2 it is set to | |
| <code class="subject rouge"><span class="pcre2-semantic">b</span></code>.</li><li>PCRE2’s handling of duplicate capture group numbers and names is not as | |
| general as Perl’s. This is a consequence of the fact the PCRE2 works internally | |
| just with numbers, using an external table to translate between numbers and | |
| names. In particular, a pattern such as <code class="regex rouge"><span class="pcre2-semantic">(?|(?<a>A)|(?<b>B))</span></code>, where the two | |
| capture groups have the same number but different names, is not supported, and | |
| causes an error at compile time. If it were allowed, it would not be possible | |
| to distinguish which group matched, because both names map to capture group | |
| number 1. To avoid this confusing situation, an error is given at compile time.</li><li>Perl used to recognize comments in some places that PCRE2 does not, for | |
| example, between the <code class="regex rouge"><span class="pcre2-semantic">(</span></code> and <code class="regex rouge"><span class="pcre2-semantic">?</span></code> at the start of a group. If the <code class="regex rouge"><span class="pcre2-semantic">/x</span></code> modifier is | |
| set, Perl allowed white space between <code class="regex rouge"><span class="pcre2-semantic">(</span></code> and <code class="regex rouge"><span class="pcre2-semantic">?</span></code> though the latest Perls give an | |
| error (for a while it was just deprecated). There may still be some cases where | |
| Perl behaves differently.</li><li>Perl, when in warning mode, gives warnings for character classes such as | |
| <code class="regex rouge"><span class="pcre2-semantic">[A-\d]</span></code> or <code class="regex rouge"><span class="pcre2-semantic">[a-[:digit:]]</span></code>. It then treats the hyphens as literals. PCRE2 has no | |
| warning features, so it gives an error in these cases because they are almost | |
| certainly user mistakes.</li><li>In PCRE2, until release 10.45, the upper/lower case character properties | |
| <code class="regex rouge"><span class="pcre2-semantic">Lu</span></code> and <code class="regex rouge"><span class="pcre2-semantic">Ll</span></code> were not affected when case-independent matching was specified. Perl has | |
| changed in this respect, and PCRE2 has now changed to match. When caseless | |
| matching is in force, <code class="regex rouge"><span class="pcre2-semantic">Lu</span></code>, <code class="regex rouge"><span class="pcre2-semantic">Ll</span></code>, and <code class="regex rouge"><span class="pcre2-semantic">Lt</span></code> (title case) | |
| are all treated as <code class="regex rouge"><span class="pcre2-semantic">Lc</span></code> (cased letter).</li><li>From release 5.32.0, Perl locks out the use of <code class="regex rouge"><span class="pcre2-semantic">\K</span></code> in lookaround | |
| assertions. From release 10.38 PCRE2 does the same by default. However, there | |
| is an option for re-enabling the previous behaviour. When this option is set, | |
| <code class="regex rouge"><span class="pcre2-semantic">\K</span></code> is acted on when it occurs in positive assertions, but is ignored in | |
| negative assertions.</li><li>PCRE2 provides some extensions to the Perl regular expression facilities. | |
| Perl 5.10 included new features that were not in earlier versions of Perl, some | |
| of which (such as named parentheses) were in PCRE2 for some time before. This | |
| list is with respect to Perl 5.38:<ol class="loweralpha compact" type="a"><li>If <code class="constant pcre2-api rouge"><span class="no">PCRE2_DOLLAR_ENDONLY</span></code> is set and <code class="constant pcre2-api rouge"><span class="no">PCRE2_MULTILINE</span></code> is not set, the <code class="regex rouge"><span class="pcre2-semantic">$</span></code> | |
| meta-character matches only at the very end of the string.</li><li>A backslash followed by a letter with no special meaning is faulted. (Perl | |
| can be made to issue a warning.)</li><li>If <code class="constant pcre2-api rouge"><span class="no">PCRE2_UNGREEDY</span></code> is set, the greediness of the repetition quantifiers is | |
| inverted, that is, by default they are not greedy, but if followed by a | |
| question mark they are.</li><li><code class="constant pcre2-api rouge"><span class="no">PCRE2_ANCHORED</span></code> can be used at matching time to force a pattern to be tried | |
| only at the first matching position in the subject string.</li><li>The <code class="constant pcre2-api rouge"><span class="no">PCRE2_NOTBOL</span></code>, <code class="constant pcre2-api rouge"><span class="no">PCRE2_NOTEOL</span></code>, <code class="constant pcre2-api rouge"><span class="no">PCRE2_NOTEMPTY</span></code> and <code class="constant pcre2-api rouge"><span class="no">PCRE2_NOTEMPTY_ATSTART</span></code> | |
| options have no Perl equivalents.</li><li>The <code class="regex rouge"><span class="pcre2-semantic">\R</span></code> escape sequence can be restricted to match only CR, | |
| LF, or CRLF | |
| by the <code class="constant pcre2-api rouge"><span class="no">PCRE2_BSR_ANYCRLF</span></code> option.</li><li>The callout facility is PCRE2-specific. Perl supports codeblocks and | |
| variable interpolation, but not general hooks on every match.</li><li>The partial matching facility is PCRE2-specific.</li><li>The alternative matching function (<code class="function pcre2-api rouge"><span class="nf">pcre2_dfa_match()</span></code>) matches in a | |
| different way and is not Perl-compatible.</li><li>PCRE2 recognizes some special sequences such as <code class="regex rouge"><span class="pcre2-semantic">(*CR)</span></code> or <code class="regex rouge"><span class="pcre2-semantic">(*NO_JIT)</span></code> at | |
| the start of a pattern. These set overall options that cannot be changed within | |
| the pattern.</li><li>PCRE2 supports non-atomic positive lookaround assertions. This is an | |
| extension to the lookaround facilities. The default, Perl-compatible | |
| lookarounds are atomic.</li><li>There are three syntactical items in patterns that can refer to a capturing | |
| group by number: back references such as <code class="regex rouge"><span class="pcre2-semantic">\g{2}</span></code>, subroutine calls such as <code class="regex rouge"><span class="pcre2-semantic">(?3)</span></code>, | |
| and condition references such as <code class="regex rouge"><span class="pcre2-semantic">(?(4)...)</span></code>. PCRE2 supports relative group | |
| numbers such as <code class="regex rouge"><span class="pcre2-semantic">+2</span></code> and <code class="regex rouge"><span class="pcre2-semantic">-4</span></code> in all three cases. Perl supports both plus and minus | |
| for subroutine calls, but only minus for back references, and no relative | |
| numbering at all for conditions.</li><li>The scan substring assertion (syntax <code class="regex rouge"><span class="pcre2-semantic">(*scs:(<em>n</em>)...)</span></code>) is a PCRE2 extension | |
| that is not available in Perl.</li></ol></li><li>Perl has different limits than PCRE2. See the | |
| <a href="./pcre2limits.html"><code>pcre2limits</code></a> | |
| documentation for details. Perl went with 5.10 from recursion to iteration | |
| keeping the intermediate matches on the heap, which is ~10% slower but does not | |
| fall into any stack-overflow limit. PCRE2 made a similar change at release | |
| 10.30, and also has many build-time and run-time customizable limits.</li><li>Unlike Perl, PCRE2 doesn’t have character set modifiers and specially no way | |
| to set characters by context just like Perl’s <code class="regex rouge"><span class="pcre2-semantic">/d</span></code>. A regular expression using | |
| <code class="constant pcre2-api rouge"><span class="no">PCRE2_UTF</span></code> and <code class="constant pcre2-api rouge"><span class="no">PCRE2_UCP</span></code> will use similar rules to Perl’s <code class="regex rouge"><span class="pcre2-semantic">/u</span></code>; something closer | |
| to <code class="regex rouge"><span class="pcre2-semantic">/a</span></code> could be selected by adding other <code>PCRE2_EXTRA_ASCII*</code> options on top.</li><li>Some recursive patterns that Perl diagnoses as infinite recursions can be | |
| handled by PCRE2, either by the interpreter or the JIT. An example is | |
| <code class="regex rouge"><span class="pcre2-semantic">(?:|(?0)abcd)(?(R)|\z)</span></code>, which matches a sequence of any number of repeated | |
| <code class="subject rouge"><span class="pcre2-semantic">abcd</span></code> substrings at the end of the subject.</li><li>Both PCRE2 and Perl error when <code class="regex rouge"><span class="pcre2-semantic">\x{</span></code> escapes are invalid, but Perl tries to | |
| recover and prints a warning if the problem was that an invalid hexadecimal | |
| digit was found. Since PCRE2 doesn’t have warnings it returns an error instead. | |
| Additionally, Perl accepts <code class="regex rouge"><span class="pcre2-semantic">\x{}</span></code> and matches NUL unlike PCRE2.</li><li>From release 10.45, PCRE2 gives an error if <code class="regex rouge"><span class="pcre2-semantic">\x</span></code> is not followed by a | |
| hexadecimal digit or a curly bracket. It used to interpret this as the NUL | |
| character. Perl still matches NUL, but warns when in warning mode in most | |
| cases.</li></ul> | |
| <h2 id="_author" class="discrete">Author</h2> | |
| <p>Philip Hazel<br> | |
| Retired from University Computing Service<br> | |
| Cambridge, England.</p> | |
| <h2 id="_revision" class="discrete">Revision</h2> | |
| <p>Last updated: 02 June 2025<br> | |
| Copyright © 1997-2024 University of Cambridge.</p></section></article></div></main><footer class="offline-footer"></footer></body></html> |