From @cpansprout

The behaviour of __SUB__ inside a format is an accident of the implementation.

As ‘one’-liners, for copy-and-paste​:

$ ./perl -Ilib -Eformat\ = -e'@​<<<<<<<<<<<<<<<<<<<<<< @​<<<<<<<<<<<<<<<<<<<<<<' -e'eval q<__SUB__//"undef", *STDOUT{FORMAT}>' -e. -e'write for 1..5'
undef FORMAT(0x7fc18102ae40)
undef FORMAT(0x7fc18102ae40)
undef FORMAT(0x7fc18102ae40)
undef FORMAT(0x7fc18102ae40)
undef FORMAT(0x7fc18102ae40)
./perl -Ilib -Eformat\ = -e'@​<<<<<<<<<<<<<<<<<<<<<< @​<<<<<<<<<<<<<<<<<<<<<<' -e'__SUB__//"undef", *STDOUT{FORMAT}' -e. -e'write for 1..5'
FORMAT(0x7f93ec02ae40) FORMAT(0x7f93ec02ae40)
FORMAT(0x7f93ec02ae40) FORMAT(0x7f93ec02ae40)
FORMAT(0x7f93ec02ae40) FORMAT(0x7f93ec02ae40)
FORMAT(0x7f93ec02ae40) FORMAT(0x7f93ec02ae40)
FORMAT(0x7f93ec02ae40) FORMAT(0x7f93ec02ae40)

More readable versions​:

use v5.16;
format =
@​<<<<<<<<<<<<<<<<<<<<<< @​<<<<<<<<<<<<<<<<<<<<<<
eval q<__SUB__//"undef", *STDOUT{FORMAT}>
.
write for 1..5
__END__

use v5.16;
format =
@​<<<<<<<<<<<<<<<<<<<<<< @​<<<<<<<<<<<<<<<<<<<<<<
__SUB__//"undef", *STDOUT{FORMAT}
.
write for 1..5
__END__

Notice that whether we have a string eval inside the format determines the output of __SUB__. Notice also that when __SUB__ is defined it is the same as the format originally invoked, even though the currently running format is a clone of it (though that is perhaps an implementation detail that should not be leaked).

What *should* __SUB__ produce inside a format? Maybe it should always just be undef.

(For those interested, the difference in behaviour has to do with the optimisation of the runcv op to a constant at compile time. Though now I don’t remember why string eval needs to affect that optimisation. I may have copied and pasted the logic from elsewhere.)

--

Father Chrysostomos