Perl 5.27.3 corrects empty-pattern reuse

An empty regular expression in Perl can mean reuse of a previous successful pattern. That rule makes an empty interpolation more consequential than it first appears. Perl 5.27.3 corrects a case where a non-threaded interpreter also treated the expression as though it had /o, because the previous successful matching operator used that modifier. The release notes say the rewriting involved could confuse the interpreter. The release history records August 21, 2017.

The fix aligns this case with threaded builds. It does not remove Perl's empty-pattern rule or redefine every pattern modifier. Its scope is the unintended compile-once treatment of m/$null/ when $null is an empty string. Understanding that distinction requires separating reuse of a previous regex from the decision to compile an interpolated expression only once.

I still find Perl's integrated regex syntax useful for one-off text work. That integration also means ordinary string values can invoke rules with history-dependent behavior. An empty variable is worth treating deliberately when it becomes part of a matching expression.

Empty input can select an earlier expression

The operator documentation for this version states that a pattern evaluating to an empty string uses the last successfully matched regular expression. Only the g and c flags on the empty pattern are honored in that case. Other flags come from the original pattern. If no match has succeeded, the expression instead acts as a genuine empty pattern that always matches.

That contract makes the result depend on earlier matching. An application cannot assume that interpolating an empty string means it has asked to match nothing meaningful. A prior match can supply a nonempty expression, with its own modifiers. An input-validation decision about empty patterns therefore belongs before the interpolation if reuse is not intended.

The documentation separately describes /o as compiling a pattern only once. Its effect does not propagate when a precompiled pattern is embedded in a larger expression, because the modifier is restricted to expressions explicitly using it. The release fix addresses an implementation that incorrectly applied compile-once behavior in the named empty-string case.

Those rules should not be collapsed into a statement that no modifiers transfer during empty-pattern reuse. The documentation explicitly describes transfer for that reuse. The bug concerns how the non-threaded interpreter treated the later matching operator and rewrote it, which could introduce behavior beyond the intended reuse of the prior compiled expression.

Build configuration should not select this behavior

The notes identify non-threaded builds as affected and say the corrected behavior matches threaded builds. This is a useful boundary for investigating a discrepancy. A Perl version alone may not describe every relevant implementation choice, and here the release gives one concrete configuration difference.

That does not mean every regex result differs across the two build forms. The documented case combines a previous matching operator using /o with a later interpolated pattern that evaluates to an empty string. Broadening it to all pattern reuse or all interpolation would lose the conditions that make the report useful.

I prefer to keep empty-pattern reuse visible when it is intentional. A compact transformation is easier to understand when its matching behavior does not depend on an unnoticed empty input. The fix preserves the language rule while removing the extra compile-once treatment that the release identifies as an interpreter error.

Numeric recognition stops at an incomplete exponent

The same snapshot changes tokenization of floating-point numbers. The tokenizer no longer consumes an exponent part when it is incomplete. That description concerns which input characters belong to the numeric token, before the rest of the parser interprets the surrounding expression.

An exponent marker is meaningful only with the remainder needed to form the exponent. Consuming an incomplete part commits characters to a number that the tokenizer has not actually recognized in full. Leaving those characters for subsequent parsing preserves the boundary between recognizing the number and deciding what follows it.

The notes identify this as issue 131725 without promising that every previously failing input becomes a valid program. This correction concerns token consumption. The surrounding source still has to satisfy the language grammar, so it would be inaccurate to describe the fix as general acceptance of malformed numeric literals.

Core inclusion and continued use are separate questions

The release also starts deprecating the bundled B::Debug module. Its notes explain that removal from core primarily concerns what is necessary to bootstrap a CPAN-capable Perl installation. It is not generally a judgement that such modules have an unsuitable design.

Installing the module from CPAN silences the core version's deprecation warning. Distributions depending on it will need to declare it as a prerequisite when it leaves core. The practical change is an explicit dependency, rather than an instruction to stop using the module. This lets the release reduce assumptions about what accompanies an interpreter while retaining a documented installation route for the component.