Perl 5.33.4 repairs stacked file tests and split assignment

Perl can evaluate several file tests against one filename with a compact expression such as -f -r $name. That convenience relies on more than operator precedence. The interpreter must obtain the filename correctly, including when the operand has behavior attached to reading its value. Perl 5.33.4 repairs that handling for stacked file tests. It also changes how optimized array assignment from split uses the interpreter's internal stack.

The release notes identify these as separate bug fixes. The history file in the tagged distribution records November 20 as the release date. Both repairs concern the implementation of concise source forms, where an optimization must preserve behavior that an expanded expression makes easier to see.

Stacked file tests must retrieve the operand correctly

The file-test report uses a regex capture as the filename. After an HTTP::Tiny operation and a match capturing a, a stacked -f -r $1 emits a warning about a filename containing a newline. The reporter observes that replacing it with -r $1 && -f _ avoids the failure. This is a specific demonstration that the stacked form did not preserve its documented relationship to the expanded expression.

The function reference bundled with 5.33.4 describes file tests and the special underscore filehandle. Ordinary tests accept a filename or handle. The underscore form reuses the previous stat structure, avoiding another system call. The stacked syntax consequently depends on both obtaining the original operand and preserving the appropriate cached information for the following test.

The release note says magic is now called correctly for stacked file-test operators. Magic is significant because a Perl scalar can require interpreter work when its value is accessed. A regex capture is not adequately modeled as an ordinary application variable whose current bytes can always be read without that work. Skipping the required handling can make a file test inspect a value other than the filename the source denotes.

my $name = 'report.txt';
if (-f -r $name) {
    print "readable regular file\n";
}

This illustrates the stacked syntax with an ordinary lexical scalar. It is not the bug's reproducer, which depends on the captured value and preceding operation. The distinction matters because a straightforward filename can exercise the syntax successfully without reaching the broken access path. A regression test needs the relevant kind of operand, not merely the same operator sequence.

I appreciate this compact syntax for occasional automation because the condition remains close to the action. Its value depends on the stacked form preserving the meaning of the documented expansion. The interpreter should not require an author to know which kinds of scalar trigger additional internal value handling.

Split no longer makes an array serve as its stack

The other repair affects the optimized @ary = split(...) form. The release notes state that the target array is no longer substituted for the value stack. This identifies the mechanism being removed, rather than presenting an unexplained claim that splitting is safer. Reusing the destination as an internal structure creates an assumption about who can modify it while the operation is still running.

The patch discussion explains that code unaware of this reuse could modify the target array during the split and provoke a segfault or panic. The change removes the stack switch and consolidates modifications to the target toward the end of the operation. Its author also identifies a tradeoff, because a large split can grow the interpreter's stack where the earlier implementation might avoid doing so.

That is a concrete change in resource handling without an intended change to the resulting list. The operation still needs storage for intermediate values. Avoiding unsafe reuse does not mean eliminating that storage, and the release should not be described as a universal memory reduction. The justification is that the destination array must remain valid under the behavior the interpreter permits while splitting proceeds.

The file-test repair and split change therefore have a useful common concern. An implementation shortcut must account for behavior beyond the simplest value access or assignment. The source expression can remain unchanged while the interpreter corrects the assumptions used to execute it. Application code benefits without adopting a new syntax or explicitly enabling an additional feature. Both changes belong to the development interpreter distributed in this snapshot.

My preference is to judge such changes by the documented behavior they restore. Here the relevant contracts include which filename a stacked test examines and whether assigning split results can safely complete. November's snapshot provides specific repairs for both, along with a documented implementation tradeoff for large splits. That gives maintainers a precise account of what changed even when ordinary test inputs already produced the expected output.