Read perl5123delta and Test the Perl 5.12.3 Changes

perl5123delta is the fastest way to check whether Perl 5.12.3 is the culprit when a point-release upgrade breaks something. Treat it as a checklist, then run a handful of read-only tests against the Perl installed on this machine.

The result is a clean split between behaviour that arrived around 5.12.3 and behaviour supplied by a much newer interpreter. Allow about fifteen minutes if Perl is already installed. This guide uses the installed perl-doc package, version 5.38.2-3.2ubuntu0.6; the manual page documents the change from Perl 5.12.2 to 5.12.3, so its historical claims say nothing about everything in Perl 5.38.2.

1. Confirm the manual and interpreter versions

Start with ordinary, read-only checks. No elevated privileges needed:

$ command -v perl
/usr/bin/perl
$ perl -v

This is perl 5, version 38, subversion 2 (v5.38.2) built for x86_64-linux-gnu-thread-multi
$ dpkg-query -W -f='${Package} ${Version}\n' perl perl-doc
perl 5.38.2-3.2ubuntu0.6
perl-doc 5.38.2-3.2ubuntu0.6
$ man perl5123delta

That last command opens the release note. Working over a terminal connection? Use man -P cat perl5123delta to send it to standard output instead. A missing manual page means the documentation package is not installed; it does not mean Perl itself is missing.

2. Read the compatibility boundary first

The page reports no intentional incompatibilities between 5.12.2 and 5.12.3. That is a release boundary, not a promise that old programs behave identically on every later Perl. It also tells you where to read next:

• Upgrading from 5.12.1? Read perl5122delta too.
• Upgrading from 5.12.0? Add perl5120delta.

The one core feature called out here: keys, values and each now operate on arrays. The page also admits this actually landed in Perl 5.12.0 and was simply missed from that release's notes. Perl 5.12.3 is the documentation point for the change, not necessarily the implementation point.

3. Verify array iteration without changing state

Run this self-contained example. It builds an in-memory array, prints its indexes and values, and exits:

$ perl -e 'my @items = qw(alpha beta gamma); print "keys=@{[keys @items]}\n"; print "values=@{[values @items]}\n"; while (my ($index, $value) = each @items) { print "each=$index:$value\n" }'
keys=0 1 2
values=alpha beta gamma
each=0:alpha
each=1:beta
each=2:gamma

For an array, the keys are indexes and the values are the elements. each returns both at once and advances its internal iterator; the output here is deterministic because the indexes run from zero to two.

Do not carry the hash mental model over too literally. Array indexes are normally dense, and assigning or deleting elements mid-loop makes the iteration harder to reason about. For a stable snapshot, iterate over a copied list instead:

$ perl -e 'my @items = qw(alpha beta gamma); for my $index (0 .. $#items) { print "$index:$items[$index]\n" }'
0:alpha
1:beta
2:gamma

That second form is ordinary indexed iteration, not a test of the release-note feature. It is often the clearer choice when you need to update the array as you go.

4. Check the deparser separately

The bug-fix section says B::Deparse can again correctly deparse no VERSION and certain constant expressions. Keep this test apart from the array test: it exercises a compiler tool, not the runtime iteration feature.

$ perl -MO=Deparse -e 'no VERSION; 1' 2>&1
Can't locate VERSION.pm in @INC (you may need to install the VERSION module) ...
BEGIN failed--compilation aborted at -e line 1.
no VERSION;
$ printf 'exit status: %s\n' "$?"
exit status: 2

That result is Perl 5.38.2's, not a successful reproduction of the old bug fix. The later interpreter treats VERSION as a module name here and stops before deparsing completes. Useful history for comparing an actual Perl 5.12.x build, but not a claim about current support.

The exact error includes the full @INC search path and may wrap differently. Got a Perl 5.12.x build handy? Run the same command there and compare the exit status and deparsed statement. If it fails because VERSION.pm cannot be found, report the missing module rather than treating that as proof the documented 5.12.3 fix is absent.

5. Keep platform notes in their historical context

The page records fixes for Solaris, VMS and VOS: release notes for those platforms, not Linux configuration instructions.

• Solaris: building miniperl with DTrace.
• VMS: PerlIO and file permissions.
• VOS: long file names and builds without IPv6 support.

Do not add a DTrace build flag, change PerlIO settings or alter IPv6 configuration just because a platform note exists here. Confirm you are building the named platform first. An ordinary Linux package user can record these as upgrade history and move on.

6. Use the reporting path for a real discrepancy

If your result differs from the documented behaviour, capture the interpreter's build details and a minimal reproducer:

$ perl -V > perl-V.txt
$ perl -e 'my @items = qw(alpha beta gamma); print join q{,}, keys @items, "\n"'
0,1,2

Keep the test input small and include the exact Perl version. The manual points to perlbug for reporting an unreported bug. Before sending anything, check the report for local paths, usernames, tokens and other details that should not leave the machine. A suspected security issue belongs on the Perl security reporting route the manual names, not a public bug discussion.

These checks install nothing, modify no Perl libraries and change no running service. Created perl-V.txt just for the report? Remove it yourself afterwards; do not delete an existing file with that name without choosing a different destination first.