A security vulnerability affecting all Perl versions prior to 5.6.1 was found in August 2000.
The vulnerability does not affect default installations and as far as is known affects only the Linux platform.

You should upgrade your Perl to 5.6.1 as soon as possible.
Patches for earlier releases exist but using the patches require full recompilation from the source code anyway,
so 5.6.1 is your best choice.

If your pointers are 64 bits wide,
the Perl malloc is no more being used because it simply does not work with 8-byte pointers.
Also,
usually the system malloc on such platforms are much better optimized for such large memory models than the Perl malloc.

The AIX dynaloading now uses in AIX releases 4.3 and newer the native dlopen interface of AIX instead of the old emulated interface.
This change will probably break backward compatibility with compiled modules.
The change was made to make Perl more compliant with other applications like modperl which are using the AIX native interface.

The Socket extension is now dynamically loaded instead of being statically built in.
This may or may not be a problem with ancient TCP/IP stacks of VMS: we do not know since we weren't able to test Perl in such configurations.

As suggested by the Unicode consortium,
the Unicode character classes now prefer scripts as opposed to blocks (as defined by Unicode); in Perl,
when the \p{In....} and the \p{In....} regular expression constructs are used.
This has changed the definition of some of those character classes.

The difference between scripts and blocks is that scripts are the glyphs used by a language or a group of languages,
while the blocks are more artificial groupings of 256 characters based on the Unicode numbering.

In general this change results in more inclusive Unicode character classes,
but changes to the other direction also do take place: for example while the script Latin includes all the Latin characters and their various diacritic-adorned versions,
it does not include the various punctuation or digits (since they are not solely Latin).

Changes in the character class semantics may have happened if a script and a block happen to have the same name,
for example Hebrew.
In such cases the script wins and \p{InHebrew} now means the script definition of Hebrew.
The block definition in still available,
though,
by appending Block to the name: \p{InHebrewBlock} means what \p{InHebrew} meant in perl 5.6.0.
For the full list of affected character classes,
see "Blocks" in perlunicode.

The current user-visible implementation of pseudo-hashes (the weird use of the first array element) is deprecated starting from Perl 5.8.0 and will be removed in Perl 5.10.0,
and the feature will be implemented differently.
Not only is the current interface rather ugly,
but the current implementation slows down normal array and hash use quite noticeably.
The fields pragma interface will remain available.

The syntaxes @a->[...] and @h->{...} have now been deprecated.

The suidperl is also considered to be too much a risk to continue maintaining and the suidperl code is likely to be removed in a future release.

The package; syntax (package without an argument has been deprecated.
Its semantics were never that clear and its implementation even less so.
If you have used that feature to disallow all but fully qualified variables,
use strict; instead.

The chdir(undef) and chdir('') behaviors to match chdir() has been deprecated.
In future versions,
chdir(undef) and chdir('') will simply fail.

In general a lot of fixing has happened in the area of Perl's understanding of numbers,
both integer and floating point.
Since in many systems the standard number parsing functions like strtoul() and atof() seem to have bugs,
Perl tries to work around their deficiencies.
This results hopefully in more accurate numbers.

The rules for allowing underscores (underbars) in numeric constants have been relaxed and simplified: now you can have an underscore between digits.

GMAGIC (right-hand side magic) could in many cases such as string concatenation be invoked too many times.

Lexicals I: lexicals outside an eval "" weren't resolved correctly inside a subroutine definition inside the eval "" if they were not already referenced in the top level of the eval""ed code.

Lexicals II: lexicals leaked at file scope into subroutines that were declared before the lexicals.

Lvalue subroutines can now return undef in list context.

The op_clear and op_null are now exported.

A new special regular expression variable has been introduced: $^N,
which contains the most-recently closed group (submatch).

utime now supports utime undef,
undef,
@files to change the file timestamps to the current time.

The Perl parser has been stress tested using both random input and Markov chain input.

eval "v200" now works.

VMS now works under PerlIO.

END blocks are now run even if you exit/die in a BEGIN block.
The execution of END blocks is now controlled by PL_exit_flags & PERL_EXIT_DESTRUCT_END.
This enables the new behaviour for perl embedders.
This will default in 5.10.
See perlembed.

B::Deparse module has been significantly enhanced.
It now can deparse almost all of the standard test suite (so that the tests still succeed).
There is a make target "test.deparse" for trying this out.

Class::Struct now assigns the array/hash element if the accessor is called with an array/hash element as the sole argument.

h2xs uses the new ExtUtils::Constant module which will affect newly created extensions that define constants.
Since the new code is more correct (if you have two constants where the first one is a prefix of the second one,
the first constant never gets defined),
less lossy (it uses integers for integer constant,
as opposed to the old code that used floating point numbers even for integer constants),
and slightly faster,
you might want to consider regenerating your extension code (the new scheme makes regenerating easy).
h2xs now also supports C trigraphs.

In AFS installations one can configure the root of the AFS to be somewhere else than the default /afs by using the Configure parameter -Dafsroot=/some/where/else.

The version of Berkeley DB used when the Perl (and,
presumably,
the DB_File extension) was built is now available as @Config{qw(db_version_major db_version_minor db_version_patch)} from Perl and as DB_VERSION_MAJOR_CFG DB_VERSION_MINOR_CFG DB_VERSION_PATCH_CFG from C.

The Thread extension is now not built at all under ithreads (Configure -Duseithreads) because it wouldn't work anyway (the Thread extension requires being Configured with -Duse5005threads).

The B::Deparse compiler backend has been so significantly improved that almost the whole Perl test suite passes after being deparsed.
A make target has been added to help in further testing: make test.deparse.

The behaviour of non-decimal but numeric string constants such as "0x23" was platform-dependent: in some platforms that was seen as 35,
in some as 0,
in some as a floating point number (don't ask).
This was caused by Perl using the operating system libraries in a situation where the result of the string to number conversion is undefined: now Perl consistently handles such strings as zero in numeric contexts.

Some versions of glibc have a broken modfl().
This affects builds with -Duselongdouble.
This version of Perl detects this brokenness and has a workaround for it.
The glibc release 2.2.2 is known to have fixed the modfl() bug.

In the regular expression diagnostics the << HERE marker introduced in 5.7.0 has been changed to be <-- HERE since too many people found the << to be too similar to here-document starters.

If you try to "pack" in perlfunc a number less than 0 or larger than 255 using the "C" format you will get an optional warning.
Similarly for the "c" format and a number less than -128 or more than 127.

Certain regex modifiers such as (?o) make sense only if applied to the entire regex.
You will an optional warning if you try to do otherwise.

Using arrays or hashes as references (e.g.
%foo->{bar} has been deprecated for a while.
Now you will get an optional warning.

The regex compiler now maintains a structure that identifies nodes in the compiled bytecode with the corresponding syntactic features of the original regex expression.
The information is attached to the new offsets member of the struct regexp.
See perldebguts for more complete information.

The C code has been made much more gcc -Wall clean.
Some warning messages still remain,
though,
so if you are compiling with gcc you will see some warnings about dubious practices.
The warnings are being worked on.

In AIX 4.2 Perl extensions that use C++ functions that use statics may have problems in that the statics are not getting initialized.
In newer AIX releases this has been solved by linking Perl with the libC_r library,
but unfortunately in AIX 4.2 the said library has an obscure bug where the various functions related to time (such as time() and gettimeofday()) return broken values,
and therefore in AIX 4.2 Perl is not linked against the libC_r.

vac 5.0.0.0 May Produce Buggy Code For Perl

The AIX C compiler vac version 5.0.0.0 may produce buggy code,
resulting in few random tests failing,
but when the failing tests are run by hand,
they succeed.
We suggest upgrading to at least vac version 5.0.1.0,
that has been known to compile Perl correctly.
"lslpp -L|grep vac.C" will tell you the vac version.

The lib/io_multihomed test may hang in HP-UX if Perl has been configured to be 64-bit.
Because other 64-bit platforms do not hang in this test,
HP-UX is suspect.
All other tests pass in 64-bit HP-UX.
The test attempts to create and connect to "multihomed" sockets (sockets which have multiple IP addresses).

If perl is configured with -Duse64bitall,
the successful result of the subtest 10 of lib/posix may arrive before the successful result of the subtest 9,
which confuses the test harness so much that it thinks the subtest 9 failed.

The op/sprintf tests 129 and 130 are known to fail on some platforms. Examples include any platform using sfio, and Compaq/Tandem's NonStop-UX. The failing platforms do not comply with the ANSI C Standard, line 19ff on page 134 of ANSI X3.159 1989 to be exact. (They produce something other than "1" and "-1" when formatting 0.6 and -0.6 using the printf format "%.0f", most often they produce "0" and "-0".)

Self-tying of arrays and hashes is broken in rather deep and hard-to-fix ways. As a stop-gap measure to avoid people from getting frustrated at the mysterious results (core dumps, most often) it is for now forbidden (you will get a fatal error even from an attempt).

Some extensions like mod_perl are known to have issues with `largefiles', a change brought by Perl 5.6.0 in which file offsets default to 64 bits wide, where supported. Modules may fail to compile at all or compile and work incorrectly. Currently there is no good solution for the problem, but Configure now provides appropriate non-largefile ccflags, ldflags, libswanted, and libs in the %Config hash (e.g., $Config{ccflags_nolargefiles}) so the extensions that are having problems can try configuring themselves without the largefileness. This is admittedly not a clean solution, and the solution may not even work at all. One potential failure is whether one can (or, if one can, whether it's a good idea) link together at all binaries with different ideas about file offsets, all this is platform-dependent.

The ability to configure Perl's numbers to use "long doubles", floating point numbers of hopefully better accuracy, is still experimental. The implementations of long doubles are not yet widespread and the existing implementations are not quite mature or standardised, therefore trying to support them is a rare and moving target. The gain of more precision may also be offset by slowdown in computations (more bits to move around, and the operations are more likely to be executed by less optimised libraries).

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://bugs.perl.org/ There may also be information at http://www.perl.com/perl/ , 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.