the ops for warn if DEBUG; would be folded to a null op (ex-const), but the nextstate op would remain, resulting in a runtime op dispatch of nextstate, nextstate, ...

The execution of a sequence of nextstate ops is indistinguishable from just the last nextstate op so the peephole optimizer now eliminates the first of a pair of nextstate ops, except where the first carries a label, since labels must not be eliminated by the optimizer and label usage isn't conclusively known at compile time.

In previous versions of Perl, magic variables like $!, %SIG, etc. would 'leak' into other packages. So %foo::SIG could be used to access signals, ${"foo::!"} (with strict mode off) to access C's errno, etc.

This was a bug, or an 'unintentional' feature, which caused various ill effects, such as signal handlers being wiped when modules were loaded, etc.

This has been fixed (or the feature has been removed, depending on how you see it).

When perlio became the default and unixio became the default bottom layer, the most common path for creating files from Perl became PerlIOUnix_open, which has always explicitly used 0666 as the permission mask.

To avoid this, 0777 is now passed as the permissions to open(). In the VMS CRTL, 0777 has a special meaning over and above intersecting with the current umask; specifically, it allows Unix syscalls to preserve native default permissions.

Opening a glob reference via open $fh, ">", \*glob will no longer cause the glob to be corrupted when the filehandle is printed to. This would cause perl to crash whenever the glob's contents were accessed [perl #77492].

The postincrement and postdecrement operators, ++ and --, used to cause leaks when being used on references. This has now been fixed.

A bug when replacing the glob of a loop variable within the loop has been fixed [perl #21469]. This means the following code will no longer crash:

for $x (...) {
*x = *y;
}

Perl would segfault if the undocumented Internals functions that used reference prototypes were called with the &foo() syntax, e.g. &Internals::SvREADONLY(undef)[perl #77776].

These functions now call SvROK on their arguments before dereferencing them with SvRV, and we test for this case in t/lib/universal.t.

When assigning a list with duplicated keys to a hash, the assignment used to return garbage and/or freed values:

An earlier release of the 5.13 series of Perl changed the semantics of opening a reference to a copy of a glob:

my $var = *STDOUT;
open my $fh, '>', \$var;

This was a mistake, and the previous behaviour from Perl 5.10 and 5.12, which is to treat \$var as a scalar reference, has now been restored.

The regular expression bracketed character class [\8\9] was effectively the same as [89\000], incorrectly matching a NULL character. It also gave incorrect warnings that the 8 and 9 were ignored. Now [\8\9] is the same as [89] and gives legitimate warnings that \8 and \9 are unrecognized escape sequences, passed-through.

The upgrade to Encode-2.40 has caused some tests in the libwww-perl distribution on CPAN to fail. (Specifically, base/message-charset.t tests 33-36 in version 5.836 of that distribution now fail.)

The upgrade to ExtUtils-MakeMaker-6.57_05 has caused some tests in the Module-Install distribution on CPAN to fail. (Specifically, 02_mymeta.t tests 5 and 21, 18_all_from.t tests 6 and 15, 19_authors.t tests 5, 13, 21 and 29, and 20_authors_with_special_characters.t tests 6, 15 and 23 in version 1.00 of that distribution now fail.)

If you find what you think is a bug, you might check the articles recently posted to the comp.lang.perl.misc newsgroup and the perl bug database at http://rt.perl.org/perlbug/ . There may also be information at http://www.perl.org/ , the Perl Home Page.

If you believe you have an unreported bug, please run the perlbug program included with your release. Be sure to trim your bug down to a tiny but sufficient test case. Your bug report, along with the output of perl -V, will be sent off to perlbug@perl.org to be analysed by the Perl porting team.

If the bug you are reporting has security implications, which make it inappropriate to send to a publicly archived mailing list, then please send it to perl5-security-report@perl.org. This points to a closed subscription unarchived mailing list, which includes all the core committers, who be able to help assess the impact of issues, figure out a resolution, and help co-ordinate the release of patches to mitigate or fix the problem across all platforms on which Perl is supported. Please only use this address for security issues in the Perl core, not for modules independently distributed on CPAN.