Perl 5.30.1 repairs a Unicode regex matching leak

A regex can return the expected answer while leaking memory on every attempt. Perl 5.30.1 repairs that condition when a string without the SVf_UTF8 flag is matched against a pattern containing Unicode literals. The maintenance notes identify a leaked scalar value on each attempt, making the frequency of matching part of the practical impact. The release history dates the release to November 10.

This is a useful maintenance change because the match result alone does not reveal the defect. A caller can accept or reject the right string while the interpreter retains an object it should release. Looking only at successful output would therefore miss an important part of the runtime's behavior.

Perl remains my preference for text transformations that need to be expressed quickly and run over substantial input. That preference makes per-attempt resource management relevant even for short programs. A compact loop can invoke the same matching path many times without containing much source code.

The two sides of a match have different representations

The release notes describe the subject as a non-SVf_UTF8 string and the pattern as containing Unicode literals. That is a representation-specific condition. It should not be generalized into a statement that every Unicode regex leaks, or that the leak requires every input string to carry a UTF-8 flag.

A pattern's character requirements and a subject scalar's internal representation can differ. The matching implementation has to reconcile them while maintaining the correct ownership of temporary values. The notes identify the externally relevant result of the bug, a leaked scalar per attempt, without providing a detailed account of every internal allocation.

That scope matters when explaining an observed memory increase. The release gives a repeated operation and a specific combination of representations. It does not provide a universal number of bytes lost per match. A scalar object and the memory ultimately attributable to it are not a fixed application-level measurement supplied by these notes.

The repair belongs to a maintenance delta from 5.30.0. It does not require a new regex construct to be useful. Programs that already use a suitable pattern can benefit through corrected runtime handling of the same operation.

Argument context can affect the interpreter stack

Another fix changes readline @foo so that the array evaluates in scalar context. Previously it evaluated in list context even though readline removes only one argument from the stack. The notes say that mismatch could underflow the stack or leave unexpected values on it.

This is a different representation problem from the regex leak. List context can supply a number of stack values that does not agree with what the receiving operation expects to consume. Correctly selecting scalar context aligns the producer's evaluation with the operation's argument contract.

The practical lesson is specific to this expression. The release is not changing every array argument in the language or making list context generally unsafe. It repairs an operation whose stack handling expected one value while its argument evaluation could provide a list.

The same release also improves sv_gets when a signal handler modifies its target scalar. That correction concerns a value changing during input handling. It reinforces why runtime behavior cannot always be understood as a single uninterrupted sequence from the source expression alone.

I value the precision of these descriptions. They identify what the operation expected and which condition violated that expectation. That gives an engineer a better basis for interpreting a maintenance release than a broad assurance that input handling has become more reliable.

Negative precision exposed a buffer overflow

Perl 5.30.1 also fixes mishandling of a negative precision in a hexadecimal floating-point formatting expression. The notes use sprintf with a star-supplied precision of negative 10000 and the a format. That case could produce a buffer overflow.

The important distinction is between a value supplied to control formatting and the value being formatted. Here the failure concerns the handling of the negative precision argument. The release does not describe it as an overflow in the floating-point number itself, and it does not supply grounds for assigning a wider vulnerability classification.

A related compiler correction prevents an erroneous assertion failure from scalar applied to a reference. These repairs address separate paths. Grouping them under maintenance is appropriate, but treating them as one mechanism would hide the conditions that make each fix relevant.

Supplementary group handling also changes. Setting $) now correctly sets supplementary group identifiers when the process has the necessary privileges. The qualification about privileges belongs to the documented behavior. Correcting the interpreter's handling does not remove the operating system's authorization requirements.

Build tools and project documentation change too

The release defines an ECHO macro needed by a dtrace build rule. The notes explain that the FreeBSD make environment apparently supplied it already, while Solaris make did not. An assumption that worked on one build platform therefore broke the corresponding rule elsewhere.

On Windows, the locale tests had two possible crash causes. For the case where the C runtime rejected a locale name encoded incorrectly for the current code page, Perl now decodes the name itself as UTF-8. The notes distinguish that repair from a separate Windows bug.

Documentation also identifies GitHub as the new canonical repository and describes the pull-request workflow. That affects how contributors find and submit changes, while the runtime fixes affect programs already executing. For an existing text-processing loop, the central result of 5.30.1 remains the removal of the documented per-attempt scalar leak when the subject representation meets a pattern containing Unicode literals.