Perl 5.30.2 repairs regex resource handling in the stable series
The maintenance release fixes a pattern leak, an invalid numeric read, and an overbroad recursion check without intentional language incompatibilities.
A regular expression can return the expected match while still leaking memory. It can also fail before matching because an internal safeguard counts the wrong operations. Perl 5.30.2 addresses both kinds of failure in the stable interpreter series. The interesting part of this maintenance release is how much correctness exists outside the visible answer to a match. Allocation lifetime and recursion accounting affect whether a program can keep doing the same work.
The 5.30.2 release notes state that no changes are intentionally incompatible with 5.30.0. An incompatibility is a bug to report. The release history preserved in the distribution records March 14 as the release date. Existing applications therefore receive these repairs within their current stable series, under an explicit compatibility policy.
A successful match can retain memory
The pattern memory-leak report describes repeated calls that interpolate a pattern into a match. Its author tested older interpreters without observing the leak and observed it with 5.28 and 5.30. The reported practical consequence was memory exhaustion on a Raspberry Pi. Those are observations from the report, not measurements that establish a universal rate of memory growth.
The reproducer is useful because it includes a comparison path. One function applies the supplied regex directly. Another first calls decode_utf8 on the pattern, and the reporter says that using this second function removes the observed leak. That difference identifies a condition worth investigating without proving that decoding is an appropriate general repair. Decoding changes how bytes are interpreted. It should follow the input's encoding contract, not become an unexplained step added merely to influence allocation behavior.
A program checking only its captured strings could miss this failure. The expected result and the lifetime of temporary interpreter objects are separate properties. A long-running process can repeat a semantically correct operation until retained allocations become its limiting resource. The release notes identify the repair as a leak in regular expression patterns, without claiming that all regex memory growth has the same cause.
I like Perl for compact text work, including transformations expressed as one-liners. That preference makes this distinction useful even for short programs. The size of the source says little about how often its matching expression runs or how much input the process handles before it exits.
A numeric property reaches numeric parsing
Another repair concerns a read beyond a buffer in grok_infnan. The original report reaches that numeric routine through a Unicode numeric-value property in a regex. AddressSanitizer reports a one-byte read beyond a heap allocation. The trace proceeds through numeric conversion and Unicode property parsing while the pattern is being compiled.
The bisection reproduced in that report points to a change that used Perl's floating-point conversion for numeric property values. The commit description explains the sequence. Convert the input to a numeric value, convert it back into a guaranteed canonical string, and use that representation for lookup. This connects an apparently specialized Unicode property expression to the interpreter's general numeric parser. The fault occurs in a dependency of property lookup, which is why examining only the final matching loop would miss it.
The evidence warrants describing an invalid read. It does not support a claim about arbitrary writes or exploitation. Maintenance notes can be brief without erasing that distinction. An operator deciding what changed should be able to distinguish a resource leak, an invalid read during compilation, and a deliberate rejection by a recursion safeguard.
Recursion checks must count recursion
The recursion-accounting issue gives a different failure mode. Its example enters a named subpattern containing a sequence of regex code blocks. The engine reports that evaluation without a position change has exceeded its limit. The issue asks whether ordinary (?{...}) blocks should increase a recursion-depth counter at all. Its author also reports that this behavior breaks Regexp::Debugger for relatively simple cases.
The release notes resolve the application-visible part by saying eval groups no longer unintentionally trigger that limit error. This does not announce the removal of protection against nonprogressing recursion. It corrects an unintended interaction between ordinary evaluation groups and the mechanism that tracks work without input consumption. Preserving a safeguard requires measuring the condition it intends to bound accurately.
The remaining repairs reinforce the same distinction between language behavior and implementation bookkeeping. Formatting with %n no longer panics in debugging builds or reports an incorrectly cached length for UTF-8-flagged output. The release also fixes a regex assertion failure, adds Configure support for GCC 10, and repairs the Windows MYMALLOC build. Each statement describes a specific supported path, without implying a new language facility.
My preference for a maintenance update is a narrow, documented change to existing behavior. This release provides that through its stated compatibility policy and issue-linked repairs. For applications using dynamic patterns, its substantive changes include reclaiming pattern allocations correctly and avoiding a false recursion failure. Those improvements apply even when every ordinary match result in an application's existing tests already looks correct.