You are viewing the version of this documentation from Perl 5.18.0. View the latest version



perldelta - what is new for perl v5.18.0


This document describes differences between the v5.16.0 release and the v5.18.0 release.

If you are upgrading from an earlier release such as v5.14.0, first read perl5160delta, which describes differences between v5.14.0 and v5.16.0.

Core Enhancements

New mechanism for experimental features

Newly-added experimental features will now require this incantation:

no warnings "experimental::feature_name";
use feature "feature_name";  # would warn without the prev line

There is a new warnings category, called "experimental", containing warnings that the feature pragma emits when enabling experimental features.

Newly-added experimental features will also be given special warning IDs, which consist of "experimental::" followed by the name of the feature. (The plan is to extend this mechanism eventually to all warnings, to allow them to be enabled or disabled individually, and not just by category.)

By saying

no warnings "experimental::feature_name";

you are taking responsibility for any breakage that future changes to, or removal of, the feature may cause.

Since some features (like ~~ or my $_) now emit experimental warnings, and you may want to disable them in code that is also run on perls that do not recognize these warning categories, consider using the if pragma like this:

no if $] >= 5.018, 'warnings', "experimental::feature_name";

Existing experimental features may begin emitting these warnings, too. Please consult perlexperiment for information on which features are considered experimental.

Hash overhaul

Changes to the implementation of hashes in perl v5.18.0 will be one of the most visible changes to the behavior of existing code.

By default, two distinct hash variables with identical keys and values may now provide their contents in a different order where it was previously identical.

When encountering these changes, the key to cleaning up from them is to accept that hashes are unordered collections and to act accordingly.

Hash randomization

The seed used by Perl's hash function is now random. This means that the order which keys/values will be returned from functions like keys(), values(), and each() will differ from run to run.

This change was introduced to make Perl's hashes more robust to algorithmic complexity attacks, and also because we discovered that it exposes hash ordering dependency bugs and makes them easier to track down.

Toolchain maintainers might want to invest in additional infrastructure to test for things like this. Running tests several times in a row and then comparing results will make it easier to spot hash order dependencies in code. Authors are strongly encouraged not to expose the key order of Perl's hashes to insecure audiences.

Further, every hash has its own iteration order, which should make it much more difficult to determine what the current hash seed is.

New hash functions

Perl v5.18 includes support for multiple hash functions, and changed the default (to ONE_AT_A_TIME_HARD), you can choose a different algorithm by defining a symbol at compile time. For a current list, consult the INSTALL document. Note that as of Perl v5.18 we can only recommend use of the default or SIPHASH. All the others are known to have security issues and are for research purposes only.

PERL_HASH_SEED environment variable now takes a hex value

PERL_HASH_SEED no longer accepts an integer as a parameter; instead the value is expected to be a binary value encoded in a hex string, such as "0xf5867c55039dc724". This is to make the infrastructure support hash seeds of arbitrary lengths, which might exceed that of an integer. (SipHash uses a 16 byte seed.)

PERL_PERTURB_KEYS environment variable added

The PERL_PERTURB_KEYS environment variable allows one to control the level of randomization applied to keys and friends.

When PERL_PERTURB_KEYS is 0, perl will not randomize the key order at all. The chance that keys changes due to an insert will be the same as in previous perls, basically only when the bucket size is changed.

When PERL_PERTURB_KEYS is 1, perl will randomize keys in a non-repeatable way. The chance that keys changes due to an insert will be very high. This is the most secure and default mode.

When PERL_PERTURB_KEYS is 2, perl will randomize keys in a repeatable way. Repeated runs of the same program should produce the same output every time.

PERL_HASH_SEED implies a non-default PERL_PERTURB_KEYS setting. Setting PERL_HASH_SEED=0 (exactly one 0) implies PERL_PERTURB_KEYS=0 (hash key randomization disabled); settng PERL_HASH_SEED to any other value implies PERL_PERTURB_KEYS=2 (deterministic and repeatable hash key randomization). Specifying PERL_PERTURB_KEYS explicitly to a different level overrides this behavior.

Hash::Util::hash_seed() now returns a string

Hash::Util::hash_seed() now returns a string instead of an integer. This is to make the infrastructure support hash seeds of arbitrary lengths which might exceed that of an integer. (SipHash uses a 16 byte seed.)

Output of PERL_HASH_SEED_DEBUG has been changed

The environment variable PERL_HASH_SEED_DEBUG now makes perl show both the hash function perl was built with, and the seed, in hex, in use for that process. Code parsing this output, should it exist, must change to accommodate the new format. Example of the new format:

$ PERL_HASH_SEED_DEBUG=1 ./perl -e1

Upgrade to Unicode 6.2

Perl now supports Unicode 6.2. A list of changes from Unicode 6.1 is at

Character name aliases may now include non-Latin1-range characters

It is possible to define your own names for characters for use in \N{...}, charnames::vianame(), etc. These names can now be comprised of characters from the whole Unicode range. This allows for names to be in your native language, and not just English. Certain restrictions apply to the characters that may be used (you can't define a name that has punctuation in it, for example). See "CUSTOM ALIASES" in charnames.

New DTrace probes

The following new DTrace probes have been added:


This new variable provides access to the filehandle that was last read. This is the handle used by $. and by tell and eof without arguments.

Regular Expression Set Operations

This is an experimental feature to allow matching against the union, intersection, etc., of sets of code points, similar to Unicode::Regex::Set. It can also be used to extend /x processing to [bracketed] character classes, and as a replacement of user-defined properties, allowing more complex expressions than they do. See "Extended Bracketed Character Classes" in perlrecharclass.

Lexical subroutines

This new feature is still considered experimental. To enable it:

use 5.018;
no warnings "experimental::lexical_subs";
use feature "lexical_subs";

You can now declare subroutines with state sub foo, my sub foo, and our sub foo. (state sub requires that the "state" feature be enabled, unless you write it as CORE::state sub foo.)

state sub creates a subroutine visible within the lexical scope in which it is declared. The subroutine is shared between calls to the outer sub.

my sub declares a lexical subroutine that is created each time the enclosing block is entered. state sub is generally slightly faster than my sub.

our sub declares a lexical alias to the package subroutine of the same name.

For more information, see "Lexical Subroutines" in perlsub.

Computed Labels

The loop controls next, last and redo, and the special dump operator, now allow arbitrary expressions to be used to compute labels at run time. Previously, any argument that was not a constant was treated as the empty string.

More CORE:: subs

Several more built-in functions have been added as subroutines to the CORE:: namespace - namely, those non-overridable keywords that can be implemented without custom parsers: defined, delete, exists, glob, pos, protoytpe, scalar, split, study, and undef.

As some of these have prototypes, prototype('CORE::...') has been changed to not make a distinction between overridable and non-overridable keywords. This is to make prototype('CORE::pos') consistent with prototype(&CORE::pos).

kill with negative signal names

kill has always allowed a negative signal number, which kills the process group instead of a single process. It has also allowed signal names. But it did not behave consistently, because negative signal names were treated as 0. Now negative signals names like -INT are supported and treated the same way as -2 [perl #112990].


See also: hash overhaul

Some of the changes in the hash overhaul were made to enhance security. Please read that section.

Storable security warning in documentation

The documentation for Storable now includes a section which warns readers of the danger of accepting Storable documents from untrusted sources. The short version is that deserializing certain types of data can lead to loading modules and other code execution. This is documented behavior and wanted behavior, but this opens an attack vector for malicious entities.

Locale::Maketext allowed code injection via a malicious template

If users could provide a translation string to Locale::Maketext, this could be used to invoke arbitrary Perl subroutines available in the current process.

This has been fixed, but it is still possible to invoke any method provided by Locale::Maketext itself or a subclass that you are using. One of these methods in turn will invoke the Perl core's sprintf subroutine.

In summary, allowing users to provide translation strings without auditing them is a bad idea.

This vulnerability is documented in CVE-2012-6329.

Avoid calling memset with a negative count

Poorly written perl code that allows an attacker to specify the count to perl's x string repeat operator can already cause a memory exhaustion denial-of-service attack. A flaw in versions of perl before v5.15.5 can escalate that into a heap buffer overrun; coupled with versions of glibc before 2.16, it possibly allows the execution of arbitrary code.

The flaw addressed to this commit has been assigned identifier CVE-2012-5195 and was researched by Tim Brown.

Incompatible Changes

See also: hash overhaul

Some of the changes in the hash overhaul are not fully compatible with previous versions of perl. Please read that section.

An unknown character name in \N{...} is now a syntax error

Previously, it warned, and the Unicode REPLACEMENT CHARACTER was substituted. Unicode now recommends that this situation be a syntax error. Also, the previous behavior led to some confusing warnings and behaviors, and since the REPLACEMENT CHARACTER has no use other than as a stand-in for some unknown character, any code that has this problem is buggy.

Formerly deprecated characters in \N{} character name aliases are now errors.

Since v5.12.0, it has been deprecated to use certain characters in user-defined \N{...} character names. These now cause a syntax error. For example, it is now an error to begin a name with a digit, such as in

my $undraftable = "\N{4F}";    # Syntax error!

or to have commas anywhere in the name. See "CUSTOM ALIASES" in charnames.

\N{BELL} now refers to U+1F514 instead of U+0007

Unicode 6.0 reused the name "BELL" for a different code point than it traditionally had meant. Since Perl v5.14, use of this name still referred to U+0007, but would raise a deprecation warning. Now, "BELL" refers to U+1F514, and the name for U+0007 is "ALERT". All the functions in charnames have been correspondingly updated.

New Restrictions in Multi-Character Case-Insensitive Matching in Regular Expression Bracketed Character Classes

Unicode has now withdrawn their previous recommendation for regular expressions to automatically handle cases where a single character can match multiple characters case-insensitively, for example, the letter LATIN SMALL LETTER SHARP S and the sequence ss. This is because it turns out to be impracticable to do this correctly in all circumstances. Because Perl has tried to do this as best it can, it will continue to do so. (We are considering an option to turn it off.) However, a new restriction is being added on such matches when they occur in [bracketed] character classes. People were specifying things such as /[\0-\xff]/i, and being surprised that it matches the two character sequence ss (since LATIN SMALL LETTER SHARP S occurs in this range). This behavior is also inconsistent with using a property instead of a range: \p{Block=Latin1} also includes LATIN SMALL LETTER SHARP S, but /[\p{Block=Latin1}]/i does not match ss. The new rule is that for there to be a multi-character case-insensitive match within a bracketed character class, the character must be explicitly listed, and not as an end point of a range. This more closely obeys the Principle of Least Astonishment. See "Bracketed Character Classes" in perlrecharclass. Note that a bug [perl #89774], now fixed as part of this change, prevented the previous behavior from working fully.

Explicit rules for variable names and identifiers

Due to an oversight, single character variable names in v5.16 were completely unrestricted. This opened the door to several kinds of insanity. As of v5.18, these now follow the rules of other identifiers, in addition to accepting characters that match the \p{POSIX_Punct} property.

There is no longer any difference in the parsing of identifiers specified by using braces versus without braces. For instance, perl used to allow ${foo:bar} (with a single colon) but not $foo:bar. Now that both are handled by a single code path, they are both treated the same way: both are forbidden. Note that this change is about the range of permissible literal identifiers, not other expressions.

Vertical tabs are now whitespace

No one could recall why \s didn't match \cK, the vertical tab. Now it does. Given the extreme rarity of that character, very little breakage is expected. That said, here's what it means:

\s in a regex now matches a vertical tab in all circumstances.

Literal vertical tabs in a regex literal are ignored when the /x modifier is used.

Leading vertical tabs, alone or mixed with other whitespace, are now ignored when interpreting a string as a number. For example:

$dec = " \cK \t 123";
$hex = " \cK \t 0xF";

say 0 + $dec;   # was 0 with warning, now 123
say int $dec;   # was 0, now 123
say oct $hex;   # was 0, now  15

/(?{})/ and /(??{})/ have been heavily reworked

The implementation of this feature has been almost completely rewritten. Although its main intent is to fix bugs, some behaviors, especially related to the scope of lexical variables, will have changed. This is described more fully in the "Selected Bug Fixes" section.

Stricter parsing of substitution replacement

It is no longer possible to abuse the way the parser parses s///e like this:

%_=(_,"Just another ");
$_="Perl hacker,\n";

given now aliases the global $_

Instead of assigning to an implicit lexical $_, given now makes the global $_ an alias for its argument, just like foreach. However, it still uses lexical $_ if there is lexical $_ in scope (again, just like foreach) [perl #114020].

The smartmatch family of features are now experimental

Smart match, added in v5.10.0 and significantly revised in v5.10.1, has been a regular point of complaint. Although there are a number of ways in which it is useful, it has also proven problematic and confusing for both users and implementors of Perl. There have been a number of proposals on how to best address the problem. It is clear that smartmatch is almost certainly either going to change or go away in the future. Relying on its current behavior is not recommended.

Warnings will now be issued when the parser sees ~~, given, or when. To disable these warnings, you can add this line to the appropriate scope:

no if $] >= 5.018, "experimental::smartmatch";

Consider, though, replacing the use of these features, as they may change behavior again before becoming stable.

Lexical $_ is now experimental

Since it was introduced in Perl v5.10, it has caused much confusion with no obvious solution:

It is our hope that lexical $_ can be rehabilitated, but this may cause changes in its behavior. Please use it with caution until it becomes stable.

readline() with $/ = \N now reads N characters, not N bytes

Previously, when reading from a stream with I/O layers such as encoding, the readline() function, otherwise known as the <> operator, would read N bytes from the top-most layer. [perl #79960]

Now, N characters are read instead.

There is no change in behaviour when reading from streams with no extra layers, since bytes map exactly to characters.

Overridden glob is now passed one argument

glob overrides used to be passed a magical undocumented second argument that identified the caller. Nothing on CPAN was using this, and it got in the way of a bug fix, so it was removed. If you really need to identify the caller, see Devel::Callsite on CPAN.

Here doc parsing

The body of a here document inside a quote-like operator now always begins on the line after the "<<foo" marker. Previously, it was documented to begin on the line following the containing quote-like operator, but that was only sometimes the case [perl #114040].

Alphanumeric operators must now be separated from the closing delimiter of regular expressions

You may no longer write something like:

m/a/and 1

Instead you must write

m/a/ and 1

with whitespace separating the operator from the closing delimiter of the regular expression. Not having whitespace has resulted in a deprecation warning since Perl v5.14.0.

qw(...) can no longer be used as parentheses

qw lists used to fool the parser into thinking they were always surrounded by parentheses. This permitted some surprising constructions such as foreach $x qw(a b c) {...}, which should really be written foreach $x (qw(a b c)) {...}. These would sometimes get the lexer into the wrong state, so they didn't fully work, and the similar foreach qw(a b c) {...} that one might expect to be permitted never worked at all.

This side effect of qw has now been abolished. It has been deprecated since Perl v5.13.11. It is now necessary to use real parentheses everywhere that the grammar calls for them.

Interaction of lexical and default warnings

Turning on any lexical warnings used first to disable all default warnings if lexical warnings were not already enabled:

$*; # deprecation warning
use warnings "void";
$#; # void warning; no deprecation warning

Now, the debugging, deprecated, glob, inplace and malloc warnings categories are left on when turning on lexical warnings (unless they are turned off by no warnings, of course).

This may cause deprecation warnings to occur in code that used to be free of warnings.

Those are the only categories consisting only of default warnings. Default warnings in other categories are still disabled by use warnings "category", as we do not yet have the infrastructure for controlling individual warnings.

state sub and our sub

Due to an accident of history, state sub and our sub were equivalent to a plain sub, so one could even create an anonymous sub with our sub { ... }. These are now disallowed outside of the "lexical_subs" feature. Under the "lexical_subs" feature they have new meanings described in "Lexical Subroutines" in perlsub.

Defined values stored in environment are forced to byte strings

A value stored in an environment variable has always been stringified. In this release, it is converted to be only a byte string. First, it is forced to be only a string. Then if the string is utf8 and the equivalent of utf8::downgrade() works, that result is used; otherwise, the equivalent of utf8::encode() is used, and a warning is issued about wide characters ("Diagnostics").

require dies for unreadable files

When require encounters an unreadable file, it now dies. It used to ignore the file and continue searching the directories in @INC [perl #113422].

gv_fetchmeth_* and SUPER

The various gv_fetchmeth_* XS functions used to treat a package whose named ended with ::SUPER specially. A method lookup on the Foo::SUPER package would be treated as a SUPER method lookup on the Foo package. This is no longer the case. To do a SUPER lookup, pass the Foo stash and the GV_SUPER flag.

split's first argument is more consistently interpreted

After some changes earlier in v5.17, split's behavior has been simplified: if the PATTERN argument evaluates to a string containing one space, it is treated the way that a literal string containing one space once was.


Module removals

The following modules will be removed from the core distribution in a future release, and will at that time need to be installed from CPAN. Distributions on CPAN which require these modules will need to list them as prerequisites.

The core versions of these modules will now issue "deprecated"-category warnings to alert you to this fact. To silence these deprecation warnings, install the modules in question from CPAN.

Note that these are (with rare exceptions) fine modules that you are encouraged to continue to use. Their disinclusion from core primarily hinges on their necessity to bootstrapping a fully functional, CPAN-capable Perl installation, not usually on concerns over their design.


The use of this pragma is now strongly discouraged. It conflates the encoding of source text with the encoding of I/O data, reinterprets escape sequences in source text (a questionable choice), and introduces the UTF-8 bug to all runtime handling of character strings. It is broken as designed and beyond repair.

For using non-ASCII literal characters in source text, please refer to utf8. For dealing with textual I/O data, please refer to Encode and open.

CPANPLUS and all included CPANPLUS::* modules

Deprecated Utilities

The following utilities will be removed from the core distribution in a future release as their associated modules have been deprecated. They will remain available with the applicable CPAN distribution.


These items are part of the CPANPLUS distribution.


This item is part of the Pod::LaTeX distribution.


This interpreter-global variable used to track the total number of Perl objects in the interpreter. It is no longer maintained and will be removed altogether in Perl v5.20.

Five additional characters should be escaped in patterns with /x

When a regular expression pattern is compiled with /x, Perl treats 6 characters as white space to ignore, such as SPACE and TAB. However, Unicode recommends 11 characters be treated thusly. We will conform with this in a future Perl version. In the meantime, use of any of the missing characters will raise a deprecation warning, unless turned off. The five characters are:


User-defined charnames with surprising whitespace

A user-defined character name with trailing or multiple spaces in a row is likely a typo. This now generates a warning when defined, on the assumption that uses of it will be unlikely to include the excess whitespace.

Various XS-callable functions are now deprecated

All the functions used to classify characters will be removed from a future version of Perl, and should not be used. With participating C compilers (e.g., gcc), compiling any file that uses any of these will generate a warning. These were not intended for public use; there are equivalent, faster, macros for most of them.

See "Character classes" in perlapi. The complete list is:

is_uni_alnum, is_uni_alnumc, is_uni_alnumc_lc, is_uni_alnum_lc, is_uni_alpha, is_uni_alpha_lc, is_uni_ascii, is_uni_ascii_lc, is_uni_blank, is_uni_blank_lc, is_uni_cntrl, is_uni_cntrl_lc, is_uni_digit, is_uni_digit_lc, is_uni_graph, is_uni_graph_lc, is_uni_idfirst, is_uni_idfirst_lc, is_uni_lower, is_uni_lower_lc, is_uni_print, is_uni_print_lc, is_uni_punct, is_uni_punct_lc, is_uni_space, is_uni_space_lc, is_uni_upper, is_uni_upper_lc, is_uni_xdigit, is_uni_xdigit_lc, is_utf8_alnum, is_utf8_alnumc, is_utf8_alpha, is_utf8_ascii, is_utf8_blank, is_utf8_char, is_utf8_cntrl, is_utf8_digit, is_utf8_graph, is_utf8_idcont, is_utf8_idfirst, is_utf8_lower, is_utf8_mark, is_utf8_perl_space, is_utf8_perl_word, is_utf8_posix_digit, is_utf8_print, is_utf8_punct, is_utf8_space, is_utf8_upper, is_utf8_xdigit, is_utf8_xidcont, is_utf8_xidfirst.

In addition these three functions that have never worked properly are deprecated: to_uni_lower_lc, to_uni_title_lc, and to_uni_upper_lc.

Certain rare uses of backslashes within regexes are now deprecated

There are three pairs of characters that Perl recognizes as metacharacters in regular expression patterns: {}, [], and (). These can be used as well to delimit patterns, as in:


Since they are metacharacters, they have special meaning to regular expression patterns, and it turns out that you can't turn off that special meaning by the normal means of preceding them with a backslash, if you use them, paired, within a pattern delimited by them. For example, in


the backslashes do not change the behavior, and this matches "f o" followed by one to three more occurrences of "o".

Usages like this, where they are interpreted as metacharacters, are exceedingly rare; we think there are none, for example, in all of CPAN. Hence, this deprecation should affect very little code. It does give notice, however, that any such code needs to change, which will in turn allow us to change the behavior in future Perl versions so that the backslashes do have an effect, and without fear that we are silently breaking any existing code.

Splitting the tokens (? and (* in regular expressions

A deprecation warning is now raised if the ( and ? are separated by white space or comments in (?...) regular expression constructs. Similarly, if the ( and * are separated in (*VERB...) constructs.

Pre-PerlIO IO implementations

In theory, you can currently build perl without PerlIO. Instead, you'd use a wrapper around stdio or sfio. In practice, this isn't very useful. It's not well tested, and without any support for IO layers or (thus) Unicode, it's not much of a perl. Building without PerlIO will most likely be removed in the next version of perl.

PerlIO supports a stdio layer if stdio use is desired. Similarly a sfio layer could be produced in the future, if needed.

Future Deprecations

Performance Enhancements

Modules and Pragmata

New Modules and Pragmata

Updated Modules and Pragmata

For a complete list of updates, run:

$ corelist --diff 5.16.0 5.18.0

You can substitute your favorite version in place of 5.16.0, too.

Removed Modules and Pragmata


Changes to Existing Documentation








The following additions or changes have been made to diagnostic output, including warnings and fatal error messages. For the complete list of diagnostic messages, see perldiag.

New Diagnostics

New Errors

New Warnings

Changes to Existing Diagnostics

Utility Changes


Configuration and Compilation


Platform Support

Discontinued Platforms


BeOS was an operating system for personal computers developed by Be Inc, initially for their BeBox hardware. The OS Haiku was written as an open source replacement for/continuation of BeOS, and its perl port is current and actively maintained.

UTS Global

Support code relating to UTS global has been removed. UTS was a mainframe version of System V created by Amdahl, subsequently sold to UTS Global. The port has not been touched since before Perl v5.8.0, and UTS Global is now defunct.


Support for VM/ESA has been removed. The port was tested on 2.3.0, which IBM ended service on in March 2002. 2.4.0 ended service in June 2003, and was superseded by Z/VM. The current version of Z/VM is V6.2.0, and scheduled for end of service on 2015/04/30.


Support for MPE/IX has been removed.


Support code relating to EPOC has been removed. EPOC was a family of operating systems developed by Psion for mobile devices. It was the predecessor of Symbian. The port was last updated in April 2002.


Support for Rhapsody has been removed.

Platform-Specific Notes


Configure now always adds -qlanglvl=extc99 to the CC flags on AIX when using xlC. This will make it easier to compile a number of XS-based modules that assume C99 [perl #113778].


There is now a workaround for a compiler bug that prevented compiling with clang++ since Perl v5.15.7 [perl #112786].


When compiling the Perl core as C++ (which is only semi-supported), the mathom functions are now compiled as extern "C", to ensure proper binary compatibility. (However, binary compatibility isn't generally guaranteed anyway in the situations where this would matter.)


Stop hardcoding an alignment on 8 byte boundaries to fix builds using -Dusemorebits.


Perl should now work out of the box on Haiku R1 Alpha 4.


libc_r was removed from recent versions of MidnightBSD and older versions work better with pthread. Threading is now enabled using pthread which corrects build errors with threading enabled on 0.4-CURRENT.


In Configure, avoid running sed commands with flags not supported on Solaris.




Building on WinCE is now possible once again, although more work is required to fully restore a clean build.

Internal Changes

Selected Bug Fixes

Known Problems


Hojung Yoon (AMORETTE), 24, of Seoul, South Korea, went to his long rest on May 8, 2013 with llama figurine and autographed TIMTOADY card. He was a brilliant young Perl 5 & 6 hacker and a devoted member of He programmed Perl, talked Perl, ate Perl, and loved Perl. We believe that he is still programming in Perl with his broken IBM laptop somewhere. He will be missed.


Perl v5.18.0 represents approximately 12 months of development since Perl v5.16.0 and contains approximately 400,000 lines of changes across 2,100 files from 113 authors.

Perl continues to flourish into its third decade thanks to a vibrant community of users and developers. The following people are known to have contributed the improvements that became Perl v5.18.0:

Aaron Crane, Aaron Trevena, Abhijit Menon-Sen, Adrian M. Enache, Alan Haggai Alavi, Alexandr Ciornii, Andrew Tam, Andy Dougherty, Anton Nikishaev, Aristotle Pagaltzis, Augustina Blair, Bob Ernst, Brad Gilbert, Breno G. de Oliveira, Brian Carlson, Brian Fraser, Charlie Gonzalez, Chip Salzenberg, Chris 'BinGOs' Williams, Christian Hansen, Colin Kuskie, Craig A. Berry, Dagfinn Ilmari Mannsåker, Daniel Dragan, Daniel Perrett, Darin McBride, Dave Rolsky, David Golden, David Leadbeater, David Mitchell, David Nicol, Dominic Hargreaves, E. Choroba, Eric Brine, Evan Miller, Father Chrysostomos, Florian Ragwitz, François Perrad, George Greer, Goro Fuji, H.Merijn Brand, Herbert Breunung, Hugo van der Sanden, Igor Zaytsev, James E Keenan, Jan Dubois, Jasmine Ahuja, Jerry D. Hedden, Jess Robinson, Jesse Luehrs, Joaquin Ferrero, Joel Berger, John Goodyear, John Peacock, Karen Etheridge, Karl Williamson, Karthik Rajagopalan, Kent Fredric, Leon Timmermans, Lucas Holt, Lukas Mai, Marcus Holland-Moritz, Markus Jansen, Martin Hasch, Matthew Horsfall, Max Maischein, Michael G Schwern, Michael Schroeder, Moritz Lenz, Nicholas Clark, Niko Tyni, Oleg Nesterov, Patrik Hägglund, Paul Green, Paul Johnson, Paul Marquess, Peter Martini, Rafael Garcia-Suarez, Reini Urban, Renee Baecker, Rhesa Rozendaal, Ricardo Signes, Robin Barker, Ronald J. Kimball, Ruslan Zakirov, Salvador Fandiño, Sawyer X, Scott Lanning, Sergey Alekseev, Shawn M Moore, Shirakata Kentaro, Shlomi Fish, Sisyphus, Smylers, Steffen Müller, Steve Hay, Steve Peters, Steven Schubiger, Sullivan Beck, Sven Strickroth, Sébastien Aperghis-Tramoni, Thomas Sibley, Tobias Leich, Tom Wyant, Tony Cook, Vadim Konovalov, Vincent Pit, Volker Schatz, Walt Mankowski, Yves Orton, Zefram.

The list above is almost certainly incomplete as it is automatically generated from version control history. In particular, it does not include the names of the (very much appreciated) contributors who reported issues to the Perl bug tracker.

Many of the changes included in this version originated in the CPAN modules included in Perl's core. We're grateful to the entire CPAN community for helping Perl to flourish.

For a more complete list of all of Perl's historical contributors, please see the AUTHORS file in the Perl source distribution.

Reporting Bugs

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 . There may also be information at , 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 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 This points to a closed subscription unarchived mailing list, which includes all the core committers, who will 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.


The Changes file for an explanation of how to view exhaustive details on what changed.

The INSTALL file for how to build Perl.

The README file for general stuff.

The Artistic and Copying files for copyright information.