5 perl5160delta - what is new for perl v5.16.0
9 This document describes differences between the 5.14.0 release and
12 If you are upgrading from an earlier release such as 5.12.0, first read
13 L<perl5140delta>, which describes differences between 5.12.0 and
18 XXX Any important notices here
20 =head1 Core Enhancements
22 =head2 C<use I<VERSION>>
24 As of this release, version declarations like C<use v5.16> now disable
25 all features before enabling the new feature bundle. This means that
26 the following holds true:
29 # only 5.16 features enabled here
31 # only 5.14 features enabled here (not 5.16)
33 C<use v5.12> and higher continue to enable strict, but explicit C<use
34 strict> and C<no strict> now override the version declaration, even
41 There is a new ":default" feature bundle that represents the set of
42 features enabled before any version declaration or C<use feature> has
43 been seen. Version declarations below 5.10 now enable the ":default"
44 feature set. This does not actually change the behaviour of C<use
45 v5.8>, because features added to the ":default" set are those that were
46 traditionally enabled by default, before they could be turned off.
48 C<$[> is now disabled under C<use v5.16>. It is part of the default
49 feature set and can be turned on or off explicitly with C<use feature
54 The new C<__SUB__> token, available under the C<current_sub> feature
55 (see L<feature>) or C<use v5.16>, returns a reference to the current
56 subroutine, making it easier to write recursive closures.
58 =head2 New and Improved Built-ins
60 =head3 More consistent C<eval>
62 The C<eval> operator sometimes treats a string argument as a sequence of
63 characters and sometimes as a sequence of bytes, depending on the
64 internal encoding. The internal encoding is not supposed to make any
65 difference, but there is code that relies on this inconsistency.
67 The new C<unicode_eval> and C<evalbytes> features (enabled under C<use
68 5.16.0> resolve this. The C<unicode_eval> feature causes C<eval
69 $string> to treat the string always as Unicode. The C<evalbytes>
70 features provides a function, itself called C<evalbytes>, which
71 evaluates its argument always as a string of bytes.
73 These features also fix oddities with source filters leaking to outer
76 See L<feature> for more detail.
78 =head3 C<substr> lvalue revamp
80 =for comment Can this be compacted some? -- rjbs, 2012-02-20
82 When C<substr> is called in lvalue or potential lvalue context with two
83 or three arguments, a special lvalue scalar is returned that modifies
84 the original string (the first argument) when assigned to.
86 Previously, the offsets (the second and third arguments) passed to
87 C<substr> would be converted immediately to match the string, negative
88 offsets being translated to positive and offsets beyond the end of the
89 string being truncated.
91 Now, the offsets are recorded without modification in the special
92 lvalue scalar that is returned, and the original string is not even
93 looked at by C<substr> itself, but only when the returned lvalue is
96 These changes result in several incompatible changes and bug fixes:
102 If the original string changes length after the call to C<substr> but
103 before assignment to its return value, negative offsets will remember
104 their position from the end of the string, affecting code like this:
106 my $string = "string";
107 my $lvalue = \substr $string, -4, 2;
108 print $lvalue, "\n"; # prints "ri"
109 $string = "bailing twine";
110 print $lvalue, "\n"; # prints "wi"; used to print "il"
112 The same thing happens with an omitted third argument. The returned
113 lvalue will always extend to the end of the string, even if the string
118 Tied (and otherwise magical) variables are no longer exempt from the
119 "Attempt to use reference as lvalue in substr" warning.
123 That warning now occurs when the returned lvalue is assigned to, not
124 when C<substr> itself is called. This only makes a difference if the
125 return value of C<substr> is referenced and assigned to later.
129 The order in which "uninitialized" warnings occur for arguments to
130 C<substr> has changed.
134 Passing a substring of a read-only value or a typeglob to a function
135 (potential lvalue context) no longer causes an immediate "Can't coerce"
136 or "Modification of a read-only value" error. That error only occurs
137 if and when the value passed is assigned to.
139 The same thing happens with the "substr outside of string" error. If
140 the lvalue is only read, not written to, it is now just a warning, as
141 with rvalue C<substr>.
145 C<substr> assignments no longer call FETCH twice if the first argument
146 is a tied variable, just once.
150 It was impossible to fix all the bugs without an incompatible change,
151 and the behaviour of negative offsets was never specified, so the
152 change was deemed acceptable.
154 =head3 Return value of C<tied>
156 The value returned by C<tied> on a tied variable is now the actual
157 scalar that holds the object to which the variable is tied. This
158 allows ties to be weakened with C<Scalar::Util::weaken(tied
161 =head2 Unicode Support
163 =head3 Supports (I<almost>) Unicode 6.1
165 Besides the addition of whole new scripts, and new characters in
166 existing scripts, this new version of Unicode, as always, makes some
167 changes to existing characters. One change that may trip up some
168 applications is that the General Category of two characters in the
169 Latin-1 range, PILCROW SIGN and SECTION SIGN, has been changed from
170 Other_Symbol to Other_Punctuation. The same change has been made for
171 a character in each of Tibetan, Ethiopic, and Aegean.
172 The code points U+3248..U+324F (CIRCLED NUMBER TEN ON BLACK SQUARE
173 through CIRCLED NUMBER EIGHTY ON BLACK SQUARE) have had their General
174 Category changed from Other_Symbol to Other_Numeric. The Line Break
175 property has changes for Hebrew and Japanese; and as a consequence of
176 other changes in 6.1, the Perl regular expression construct C<\X> now
177 works differently for some characters in Thai and Lao.
179 New aliases (synonyms) have been defined for many property values;
180 these, along with the previously existing ones, are all cross indexed in
183 The return value of C<charnames::viacode()> is affected by other
186 Code point Old Name New Name
187 U+000A LINE FEED (LF) LINE FEED
188 U+000C FORM FEED (FF) FORM FEED
189 U+000D CARRIAGE RETURN (CR) CARRIAGE RETURN
190 U+0085 NEXT LINE (NEL) NEXT LINE
191 U+008E SINGLE-SHIFT 2 SINGLE-SHIFT-2
192 U+008F SINGLE-SHIFT 3 SINGLE-SHIFT-3
193 U+0091 PRIVATE USE 1 PRIVATE USE-1
194 U+0092 PRIVATE USE 2 PRIVATE USE-2
195 U+2118 SCRIPT CAPITAL P WEIERSTRASS ELLIPTIC FUNCTION
197 Perl will accept any of these names as input, but
198 C<charnames::viacode()> now returns the new name of each pair. The
199 change for U+2118 is considered by Unicode to be a correction, that is
200 the original name was a mistake (but again, it will remain forever valid
201 to use it to refer to U+2118). But most of these changes are the
202 fallout of the mistake Unicode 6.0 made in naming a character used in
203 Japanese cell phones to be "BELL", which conflicts with the long
204 standing industry use of (and Unicode's recommendation to use) that name
205 to mean the ASCII control character at U+0007. As a result, that name
206 has been deprecated in Perl since v5.14; and any use of it will raise a
207 warning message (unless turned off). The name "ALERT" is now the
208 preferred name for this code point, with "BEL" being an acceptable short
209 form. The name for the new cell phone character, at code point U+1F514,
210 remains undefined in this version of Perl (hence we don't quite
211 implement all of Unicode 6.1), but starting in v5.18, BELL will mean
212 this character, and not U+0007.
214 Unicode has taken steps to make sure that this sort of mistake does not
215 happen again. The Standard now includes all the generally accepted
216 names and abbreviations for control characters, whereas previously it
217 didn't (though there were recommended names for most of them, which Perl
218 used). This means that most of those recommended names are now
219 officially in the Standard. Unicode did not recommend names for the
220 four code points listed above between U+008E and U+008F, and in
221 standardizing them Unicode subtly changed the names that Perl had
222 previously given them, by replacing the final blank in each name by a
223 hyphen. Unicode also officially accepts names that Perl had deprecated,
224 such as FILE SEPARATOR. Now the only deprecated name is BELL.
225 Finally, Perl now uses the new official names instead of the old
226 (now considered obsolete) names for the first four code points in the
227 list above (the ones which have the parentheses in them).
229 Now that the names have been placed in the Unicode standard, these kinds
230 of changes should not happen again, though corrections, such as to
231 U+2118, are still possible.
233 Unicode also added some name abbreviations, which Perl now accepts:
235 TAB for CHARACTER TABULATION;
236 NEW LINE, END OF LINE, NL, and EOL for LINE FEED;
237 LOCKING-SHIFT ONE for SHIFT OUT;
238 LOCKING-SHIFT ZERO for SHIFT IN;
239 and ZWNBSP for ZERO WIDTH NO-BREAK SPACE.
241 More details on this version of Unicode are provided in
242 L<http://www.unicode.org/versions/Unicode6.1.0/>.
244 =head3 C<use charnames> is no longer needed for C<\N{I<name>}>
246 When C<\N{I<name>}> is encountered, the C<charnames> module is now
247 automatically loaded when needed as if the C<:full> and C<:short>
248 options had been specified. See L<charnames> for more information.
250 =head3 C<\N{...}> can now have Unicode loose name matching
252 This is described in the C<charnames> item in
253 L</Updated Modules and Pragmata> below.
255 =head3 Unicode Symbol Names
257 Perl now has proper support for Unicode in symbol names. It used to be
258 that C<*{$foo}> would ignore the internal UTF8 flag and use the bytes of
259 the underlying representation to look up the symbol. That meant that
260 C<*{"\x{100}"}> and C<*{"\xc4\x80"}> would return the same thing. All
261 these parts of Perl have been fixed to account for Unicode:
267 Method names (including those passed to C<use overload>)
271 Typeglob names (including names of variables, subroutines and filehandles)
279 Constant subroutine names (not null-clean yet)
287 Symbolic dereferencing
291 Second argument to C<bless()> and C<tie()>
295 Return value of C<ref()>
299 Package names returned by C<caller()>
303 Subroutine prototypes
311 Various warnings and error messages that mention variable names or values,
316 In addition, a parsing bug has been fixed that prevented C<*{Ć©}> from
317 implicitly quoting the name, but instead interpreted it as C<*{+Ć©}>, which
318 would cause a strict violation.
320 C<*{"*a::b"}> automatically strips off the * if it is followed by an ASCII
321 letter. That has been extended to all Unicode identifier characters.
323 C<$Ć©> is now subject to "Used only once" warnings. It used to be exempt,
324 as it was treated as a punctuation variable.
326 Also, single-character Unicode punctuation variables (like $ā°) are now
327 supported [perl #69032]. They are also supported with C<our> and C<my>,
328 but that is a mistake that will be fixed before 5.16.
330 =head3 Improved ability to mix locales and Unicode, including UTF-8 locales
332 An optional parameter has been added to C<use locale>
334 use locale ':not_characters';
336 which tells Perl to use all but the C<LC_CTYPE> and C<LC_COLLATE>
337 portions of the current locale. Instead, the character set is assumed
338 to be Unicode. This allows locales and Unicode to be seamlessly mixed,
339 including the increasingly frequent UTF-8 locales. When using this
340 hybrid form of locales, the C<:locale> layer to the L<open> pragma can
341 be used to interface with the file system, and there are CPAN modules
342 available for ARGV and environment variable conversions.
344 Full details are in L<perllocale>.
346 =head3 New function C<fc> and corresponding escape sequence C<\F> for Unicode foldcase
348 Unicode foldcase is an extension to lowercase that gives better results
349 when comparing two strings case-insensitively. It has long been used
350 internally in regular expression C</i> matching. Now it is available
351 explicitly through the new C<fc> function call (enabled by
352 S<C<"use feature 'fc'">>, or C<use v5.16>, or explicitly callable via
353 C<CORE::fc>) or through the new C<\F> sequence in double-quotish
356 Full details are in L<perlfunc/fc>.
358 =head3 The Unicode C<Script_Extensions> property is now supported.
360 New in Unicode 6.0, this is an improved C<Script> property. Details
361 are in L<perlunicode/Scripts>.
365 =head3 Improved typemaps for Some Builtin Types
367 Most XS authors will be aware that there is a longstanding bug in the
368 OUTPUT typemap for T_AVREF (C<AV*>), T_HVREF (C<HV*>), T_CVREF (C<CV*>),
369 and T_SVREF (C<SVREF> or C<\$foo>) that requires manually decrementing
370 the reference count of the return value instead of the typemap taking
371 care of this. For backwards-compatibility, this cannot be changed in the
372 default typemaps. But we now provide additional typemaps
373 C<T_AVREF_REFCOUNT_FIXED>, etc. that do not exhibit this bug. Using
374 them in your extension is as simple as having one line in your
377 HV* T_HVREF_REFCOUNT_FIXED
379 =head3 C<is_utf8_char()>
381 The XS-callable function C<is_utf8_char()>, when presented with
382 malformed UTF-8 input, can read up to 12 bytes beyond the end of the
383 string. This cannot be fixed without changing its API. It is not
384 called from CPAN. The documentation now describes how to use it
387 =head3 Added C<is_utf8_char_buf()>
389 This function is designed to replace the deprecated L</is_utf8_char()>
390 function. It includes an extra parameter to make sure it doesn't read
391 past the end of the input buffer.
393 =head3 Other C<is_utf8_foo()> functions, as well as C<utf8_to_foo()>, etc.
395 Most of the other XS-callable functions that take UTF-8 encoded input
396 implicitly assume that the UTF-8 is valid (not malformed) in regards to
397 buffer length. Do not do things such as change a character's case or
398 see if it is alphanumeric without first being sure that it is valid
399 UTF-8. This can be safely done for a whole string by using one of the
400 functions C<is_utf8_string()>, C<is_utf8_string_loc()>, and
401 C<is_utf8_string_loclen()>.
405 Many new functions have been added to the API for manipulating lexical
406 pads. See L<perlapi/Pad Data Structures> for more information.
408 =head2 Changes to Special Variables
410 =head3 C<$$> can be assigned to
412 C<$$> was made read-only in Perl 5.8.0. But only sometimes: C<local $$>
413 would make it writable again. Some CPAN modules were using C<local $$> or
414 XS code to bypass the read-only check, so there is no reason to keep C<$$>
415 read-only. (This change also allowed a bug to be fixed while maintaining
416 backward compatibility.)
418 =head3 C<$^X> converted to an absolute path on FreeBSD, OS X and Solaris
420 C<$^X> is now converted to an absolute path on OS X, FreeBSD (without
421 needing F</proc> mounted) and Solaris 10 and 11. This augments the
422 previous approach of using F</proc> on Linux, FreeBSD and NetBSD
423 (in all cases, where mounted).
425 This makes relocatable perl installations more useful on these platforms.
426 (See "Relocatable @INC" in F<INSTALL>)
428 =head2 Debugger Changes
430 =head3 Features inside the debugger
432 The current Perl's L<feature> bundle is now enabled for commands entered
433 in the interactive debugger.
435 =head3 New option for the debugger's B<t> command
437 The B<t> command in the debugger, which toggles tracing mode, now
438 accepts a numeric argument that determines how many levels of subroutine
441 =head3 C<enable> and C<disable>
443 The debugger now has C<disable> and C<enable> commands for disabling
444 existing breakpoints and reƫnabling them. See L<perldebug>.
446 =head3 Breakpoints with file names
448 The debugger's "b" command for setting breakpoints now allows a line
449 number to be prefixed with a file name. See
450 L<perldebug/"b [file]:[line] [condition]">.
452 =head2 The C<CORE> Namespace
454 =for comment This needs to be rewritten for 5.16 -- rjbs, 2012-02-20
456 The C<CORE::> prefix can now be used on keywords enabled by
457 L<feature.pm|feature>, even outside the scope of C<use feature>. Relevant
458 documentation files L<CORE>, L<feature>, L<perlfunc>, L<perlsub>, and
459 L<perlsyn> have been updated.
461 Perl 5.15.2 introduced subroutines in the CORE namespace. Most of them
462 could only be called as barewords; i.e., they could be aliased at compile
463 time and then inlined under new names.
465 Almost all of these functions can now be called through references and via
466 C<&foo()> syntax, bypassing the prototype. See L<CORE> for a list of the
471 =head3 Anonymous handles
473 Automatically generated file handles are now named __ANONIO__ when the
474 variable name cannot be determined, rather than $__ANONIO__.
476 =head3 Autoloaded sort Subroutines
478 Custom sort subroutines can now be autoloaded [perl #30661]:
481 @sorted = sort foo @list; # uses AUTOLOAD
483 =head3 C<continue> no longer requires the "switch" feature
485 The C<continue> keyword has two meanings. It can introduce a C<continue>
486 block after a loop, or it can exit the current C<when> block. Up till now,
487 the latter meaning was only valid with the "switch" feature enabled, and
488 was a syntax error otherwise. Since the main purpose of feature.pm is to
489 avoid conflicts with user-defined subroutines, there is no reason for
490 C<continue> to depend on it.
492 =head3 The C<\$> prototype accepts any scalar lvalue
494 The C<\$> and C<\[$]> subroutine prototypes now accept any scalar lvalue
495 argument. Previously they only accepted scalars beginning with C<$> and
496 hash and array elements. This change makes them consistent with the way
497 the built-in C<read> and C<recv> functions (among others) parse their
498 arguments. This means that one can override the built-in functions with
499 custom subroutines that parse their arguments the same way.
501 =head3 DTrace probes for interpreter phase change
503 The C<phase-change> probes will fire when the interpreter's phase
504 changes, which tracks the C<${^GLOBAL_PHASE}> variable. C<arg0> is
505 the new phase name; C<arg1> is the old one. This is useful mostly
506 for limiting your instrumentation to one or more of: compile time,
507 run time, destruct time.
509 =head3 C<__FILE__()> Syntax
511 The C<__FILE__>, C<__LINE__> and C<__PACKAGE__> tokens can now be written
512 with an empty pair of parentheses after them. This makes them parse the
513 same way as C<time>, C<fork> and other built-in functions.
515 =head2 C<_> in subroutine prototypes
517 The C<_> character in subroutine prototypes is now allowed before C<@> or
522 =head2 Use C<is_utf8_char_buf()> and not C<is_utf8_char()>
524 The latter function is now deprecated because its API is insufficient to
525 guarantee that it doesn't read (up to 12 bytes in the worst case) beyond
526 the end of its input string. See
527 L<is_utf8_char_buf()|/Added is_utf8_char_buf()>.
529 =head2 C<File::Glob::bsd_glob()> memory error with GLOB_ALTDIRFUNC (CVE-2011-2728).
531 Calling C<File::Glob::bsd_glob> with the unsupported flag
532 GLOB_ALTDIRFUNC would cause an access violation / segfault. A Perl
533 program that accepts a flags value from an external source could expose
534 itself to denial of service or arbitrary code execution attacks. There
535 are no known exploits in the wild. The problem has been corrected by
536 explicitly disabling all unsupported flags and setting unused function
537 pointers to null. Bug reported by ClƩment Lecigne.
539 =head2 Privileges are now set correctly when assigning to C<$(>
541 A hypothetical bug (probably non-exploitable in practice) due to the
542 incorrect setting of the effective group ID while setting C<$(> has been
543 fixed. The bug would only have affected systems that have C<setresgid()>
544 but not C<setregid()>, but no such systems are known of.
548 =head2 Don't read the Unicode data base files in F<lib/unicore>
550 It is now deprecated to directly read the Unicode data base files.
551 These are stored in the F<lib/unicore> directory. Instead, you should
552 use the new functions in L<Unicode::UCD>. These provide a stable API,
553 and give complete information.
555 Perl may at some point in the future change or remove the files. The
556 file most likely for applications to have used is
557 F<lib/unicore/ToDigit.pl>. L<Unicode::UCD/prop_invmap()> can be used to
558 get at its data instead.
560 =head2 C<is_utf8_char()>
562 This function is deprecated because it could read beyond the end of the
563 input string. Use the new L<is_utf8_char_buf()|/Added is_utf8_char_buf()>
566 =head1 Future Deprecations
568 This section serves as a notice of feature that are I<likely> to be
569 removed or L<deprecated|perlpolicy/deprecated> in the next release of
570 perl (5.18.0). If your code depends on these features, you should
571 contact the Perl 5 Porters via the L<mailing
572 list|http://lists.perl.org/list/perl5-porters.html> or L<perlbug> to
573 explain your use case and inform the deprecation process.
577 These modules may be marked as deprecated I<from the core>. This only
578 means that they will no longer be installed by default with the core
579 distribution, but will remain available on the CPAN.
597 Pod::Parser, Pod::LaTeX
613 =head2 Platforms with no supporting programmers:
615 The platforms will probably have their special build support removed during the
616 5.17.0 development series.
654 =head2 Other Future Deprecations
660 Swapping of $< and $>
662 https://rt.perl.org/rt3/Ticket/Display.html?id=96212
670 =head1 Incompatible Changes
672 =head2 Special blocks called in void context
674 Special blocks (C<BEGIN>, C<CHECK>, C<INIT>, C<UNITCHECK>, C<END>) are now
675 called in void context. This avoids wasteful copying of the result of the
676 last statement [perl #108794].
678 =head2 The C<overloading> pragma and regexp objects
680 With C<no overloading>, regular expression objects returned by C<qr//> are
681 now stringified as "Regexp=REGEXP(0xbe600d)" instead of the regular
682 expression itself [perl #108780].
684 =head2 Two XS typemap Entries removed
686 Two presumably unused XS typemap entries have been removed from the
687 core typemap: T_DATAUNIT and T_CALLBACK. If you are, against all odds,
688 a user of these, please see the instructions on how to regain them
691 =head2 Unicode 6.1 has incompatibilities with Unicode 6.0
693 These are detailed in L</Supports (almost) Unicode 6.1> above.
695 =head2 Borland compiler
697 All support for the Borland compiler has been dropped. The code had not
698 worked for a long time anyway.
700 =head2 Certain deprecated Unicode properties are no longer supported by default
702 Perl should never have exposed certain Unicode properties that are used
703 by Unicode internally and not meant to be publicly available. Use of
704 these has generated deprecated warning messages since Perl 5.12. The
705 removed properties are Other_Alphabetic,
706 Other_Default_Ignorable_Code_Point, Other_Grapheme_Extend,
707 Other_ID_Continue, Other_ID_Start, Other_Lowercase, Other_Math, and
710 Perl may be recompiled to include any or all of them; instructions are
712 L<perluniprops/Unicode character properties that are NOT accepted by Perl>.
714 =head2 Dereferencing IO thingies as typeglobs
716 The C<*{...}> operator, when passed a reference to an IO thingy (as in
717 C<*{*STDIN{IO}}>), creates a new typeglob containing just that IO object.
719 Previously, it would stringify as an empty string, but some operators would
720 treat it as undefined, producing an "uninitialized" warning.
722 Having a typeglob appear as an empty string is a side effect of the
723 implementation that has caused various bugs over the years.
725 The solution was to make it stringify like a normal anonymous typeglob,
726 like those produced by C<< open($foo->{bar}, ...) >> [perl #96326].
728 =head2 User-defined case changing operations.
730 This feature was deprecated in Perl 5.14, and has now been removed.
731 The CPAN module L<Unicode::Casing> provides better functionality without
732 the drawbacks that this feature had, as are detailed in the 5.14
734 L<http://perldoc.perl.org/5.14.0/perlunicode.html#User-Defined-Case-Mappings-%28for-serious-hackers-only%29>
736 =head2 XSUBs are now 'static'
738 XSUB C functions are now 'static', that is, they are not visible from
739 outside the compilation unit. Users can use the new C<XS_EXTERNAL(name)>
740 and C<XS_INTERNAL(name)> macros to pick the desired linking behaviour.
741 The ordinary C<XS(name)> declaration for XSUBs will continue to declare
742 non-'static' XSUBs for compatibility, but the XS compiler,
743 C<ExtUtils::ParseXS> (C<xsubpp>) will emit 'static' XSUBs by default.
744 C<ExtUtils::ParseXS>'s behaviour can be reconfigured from XS using the
745 C<EXPORT_XSUB_SYMBOLS> keyword, see L<perlxs> for details.
747 =head2 Weakening read-only references
749 Weakening read-only references is no longer permitted. It should never
750 hove worked anyway, and in some cases could result in crashes.
752 =head2 Tying scalars that hold typeglobs
754 Attempting to tie a scalar after a typeglob was assigned to it would
755 instead tie the handle in the typeglob's IO slot. This meant that it was
756 impossible to tie the scalar itself. Similar problems affected C<tied> and
757 C<untie>: C<tied $scalar> would return false on a tied scalar if the last
758 thing returned was a typeglob, and C<untie $scalar> on such a tied scalar
761 We fixed this problem before Perl 5.14.0, but it caused problems with some
762 CPAN modules, so we put in a deprecation cycle instead.
764 Now the deprecation has been removed and this bug has been fixed. So
765 C<tie $scalar> will always tie the scalar, not the handle it holds. To tie
766 the handle, use C<tie *$scalar> (with an explicit asterisk). The same
767 applies to C<tied *$scalar> and C<untie *$scalar>.
769 =head2 IPC::Open3 no longer provides C<xfork()>, C<xclose_on_exec()>
772 All three functions were private, undocumented and unexported. They do
773 not appear to be used by any code on CPAN. Two have been inlined and one
776 =head2 C<$$> no longer caches PID
778 Previously, if one embeds Perl or uses XS and calls fork(3) from C, Perls
779 notion of C<$$> could go out of sync with what getpid() returns. By always
780 fetching the value of C<$$> via getpid(), this potential bug is eliminated.
781 Code that depends on the caching behavior will break. As described in
782 L</Core Enhancements>, C<$$> is now writable, but it will be reset during a
785 =head2 C<$$> and C<getppid()> no longer emulate POSIX semantics under LinuxThreads
787 The POSIX emulation of C<$$> and C<getppid()> under the obsolete
788 LinuxThreads implementation has been removed (the C<$$> emulation was
789 actually removed in v5.15.0). This only impacts users of Linux 2.4 and
790 users of Debian GNU/kFreeBSD up to and including 6.0, not the vast
791 majority of Linux installations that use NPTL threads.
793 This means that C<getppid()> like C<$$> is now always guaranteed to
794 return the OS's idea of the current state of the process, not perl's
795 cached version of it.
797 See the documentation for L<$$|perlvar/$$> for details.
799 =head2 C<< $< >>, C<< $> >>, C<$(> and C<$)> are no longer cached
801 Similarly to the changes to C<$$> and C<getppid()> the internal
802 caching of C<< $< >>, C<< $> >>, C<$(> and C<$)> has been removed.
804 When we cached these values our idea of what they were would drift out
805 of sync with reality if someone (e.g. someone embedding perl) called
806 sete?[ug]id() without updating C<PL_e?[ug]id>. Having to deal with
807 this complexity wasn't worth it given how cheap the C<gete?[ug]id()>
810 This change will break a handful of CPAN modules that use the XS-level
811 C<PL_uid>, C<PL_gid>, C<PL_euid> or C<PL_egid> variables.
813 The fix for those breakages is to use C<PerlProc_gete?[ug]id()> to
814 retrieve them (e.g. C<PerlProc_getuid()>), and not to assign to
815 C<PL_e?[ug]id> if you change the UID/GID/EUID/EGID. There is no longer
816 any need to do so since perl will always retrieve the up-to-date
817 version of those values from the OS.
819 =head2 Which Non-ASCII characters get quoted by C<quotemeta> and C<\Q> has changed
821 This is unlikely to result in a real problem, as Perl does not attach
822 special meaning to any non-ASCII character, so it is currently
823 irrelevant which are quoted or not. This change fixes bug [perl #77654] and
824 bring Perl's behavior more into line with Unicode's recommendations.
825 See L<perlfunc/quotemeta>.
827 =head1 Performance Enhancements
833 Improved performance for Unicode properties in regular expressions
835 =for comment Can this be compacted some? -- rjbs, 2012-02-20
837 Matching a code point against a Unicode property is now done via a
838 binary search instead of linear. This means for example that the worst
839 case for a 1000 item property is 10 probes instead of 1000. This
840 inefficiency has been compensated for in the past by permanently storing
841 in a hash the results of a given probe plus the results for the adjacent
842 64 code points, under the theory that near-by code points are likely to
843 be searched for. A separate hash was used for each mention of a Unicode
844 property in each regular expression. Thus, C<qr/\p{foo}abc\p{foo}/>
845 would generate two hashes. Any probes in one instance would be unknown
846 to the other, and the hashes could expand separately to be quite large
847 if the regular expression were used on many different widely-separated
848 code points. This can lead to running out of memory in extreme cases.
849 Now, however, there is just one hash shared by all instances of a given
850 property. This means that if C<\p{foo}> is matched against "A" in one
851 regular expression in a thread, the result will be known immediately to
852 all regular expressions, and the relentless march of using up memory is
857 Version declarations with the C<use> keyword (e.g., C<use 5.012>) are now
858 faster, as they enable features without loading F<feature.pm>.
862 C<local $_> is faster now, as it no longer iterates through magic that it
863 is not going to copy anyway.
867 Perl 5.12.0 sped up the destruction of objects whose classes define
868 empty C<DESTROY> methods (to prevent autoloading), by simply not
869 calling such empty methods. This release takes this optimisation a
870 step further, by not calling any C<DESTROY> method that begins with a
871 C<return> statement. This can be useful for destructors that are only
874 use constant DEBUG => 1;
875 sub DESTROY { return unless DEBUG; ... }
877 Constant-folding will reduce the first statement to C<return;> if DEBUG
878 is set to 0, triggering this optimisation.
882 Assigning to a variable that holds a typeglob or copy-on-write scalar
883 is now much faster. Previously the typeglob would be stringified or
884 the copy-on-write scalar would be copied before being clobbered.
888 Assignment to C<substr> in void context is now more than twice its
889 previous speed. Instead of creating and returning a special lvalue
890 scalar that is then assigned to, C<substr> modifies the original string
895 C<substr> no longer calculates a value to return when called in void
898 =item Literal C<"{"> characters in regular expression patterns
900 It is planned starting in v5.20 to require a literal C<"{"> to be
901 escaped by, for example, preceding it with a backslash. In v5.18, a
902 deprecated warning message will be emitted for all such uses. Note that
903 this only affects patterns which are to match a literal C<"{">. Other
904 uses of this character, such as part of a quantifier or sequence like in
905 the ones below are completely unaffected:
911 The removal of this will allow extensions to pattern syntax, and better
912 error checking of existing syntax. See L<perlre/Quantifiers> for an
921 Due to changes in L<File::Glob>, Perl's C<glob> function and its C<<
922 <...> >> equivalent are now much faster. The splitting of the pattern
923 into words has been rewritten in C, resulting in speed-ups of 20% in
926 This does not affect VMS, as it does not use File::Glob.
930 The short-circuiting operators C<&&>, C<||>, and C<//>, when chained
931 (such as C<$a || $b || $c>), are now considerably faster to short-circuit,
932 due to reduced optree traversal.
936 The implementation of C<s///r> makes one fewer copy of the scalar's value.
940 C<study> is now a no-op.
944 Recursive calls to lvalue subroutines in lvalue scalar context use less
949 =head1 Modules and Pragmata
951 XXX All changes to installed files in F<cpan/>, F<dist/>, F<ext/> and F<lib/>
952 go here. If Module::CoreList is updated, generate an initial draft of the
953 following sections using F<Porting/corelist-perldelta.pl>, which prints stub
954 entries to STDOUT. Results can be pasted in place of the '=head2' entries
955 below. A paragraph summary for important changes should then be added by hand.
956 In an ideal world, dual-life modules would have a F<Changes> file that could be
959 [ Within each section, list entries as a =item entry ]
961 =head2 Deprecated Modules
965 =item L<Version::Requirements>
967 Version::Requirements is now DEPRECATED, use CPAN::Meta::Requirements,
968 which is a drop-in replacement. It will be deleted from perl.git blead
973 =head2 New Modules and Pragmata
979 L<arybase> -- this new module implements the C<$[> variable.
983 C<PerlIO::mmap> 0.010 has been added to the Perl core.
985 The C<mmap> PerlIO layer is no longer implemented by perl itself, but has
986 been moved out into the new L<PerlIO::mmap> module.
990 =head2 Updated Modules and Pragmata
996 L<XXX> has been upgraded from version 0.69 to version 0.70.
1000 =head2 Removed Modules and Pragmata
1002 As promised in Perl 5.14.0's release notes, the following modules have
1003 been removed from the core distribution, and if needed should be installed
1010 C<Devel::DProf> has been removed from the Perl core. Prior version was
1015 C<Shell> has been removed from the Perl core. Prior version was 0.72_01.
1019 =head1 Documentation
1021 =head2 New Documentation
1023 =head3 L<perldtrace>
1025 L<perldtrace> describes Perl's DTrace support, listing the provided probes
1026 and gives examples of their use.
1028 =head3 L<perlexperiment>
1030 This document is intended to provide a list of experimental features in
1031 Perl. It is still a work in progress.
1035 This a new OO tutorial. It focuses on basic OO concepts, and then recommends
1036 that readers choose an OO framework from CPAN.
1038 =head3 L<perlxstypemap>
1040 The new manual describes the XS typemapping mechanism in unprecedented
1041 detail and combines new documentation with information extracted from
1042 L<perlxs> and the previously unofficial list of all core typemaps.
1044 =head2 Changes to Existing Documentation
1052 The HV API has long accepted negative lengths to indicate that the key is
1053 in UTF8. Now this is documented.
1057 The C<boolSV()> macro is now documented.
1067 C<dbmopen> treats a 0 mode as a special case, that prevents a nonexistent
1068 file from being created. This has been the case since Perl 5.000, but was
1069 never documented anywhere. Now the perlfunc entry mentions it
1074 As an accident of history, C<open $fh, "<:", ...> applies the default
1075 layers for the platform (C<:raw> on Unix, C<:crlf> on Windows), ignoring
1076 whatever is declared by L<open.pm|open>. This seems such a useful feature
1077 it has been documented in L<perlfunc|perlfunc/open> and L<open>.
1081 The entry for C<split> has been rewritten. It is now far clearer than
1092 A new section, L<Autoloading with XSUBs|perlguts/Autoloading with XSUBs>,
1093 has been added, which explains the two APIs for accessing the name of the
1098 Some of the function descriptions in L<perlguts> were confusing, as it was
1099 not clear whether they referred to the function above or below the
1100 description. This has been clarified [perl #91790].
1110 This document has been rewritten from scratch, and its coverage of various OO
1111 concepts has been expanded.
1121 Documentation of the smartmatch operator has been reworked and moved from
1122 perlsyn to perlop where it belongs.
1124 It has also been corrected for the case of C<undef> on the left-hand
1125 side. The list of different smart match behaviours had an item in the
1130 Documentation of the ellipsis statement (C<...>) has been reworked and
1131 moved from perlop to perlsyn.
1135 The explanation of bitwise operators has been expanded to explain how they
1136 work on Unicode strings (5.14.1).
1140 The section on the triple-dot or yada-yada operator has been moved up, as
1141 it used to separate two closely related sections about the comma operator
1146 More examples for C<m//g> have been added (5.14.1).
1150 The C<<< <<\FOO >>> here-doc syntax has been documented (5.14.1).
1154 =head3 L<perlpragma>
1160 There is now a standard convention for naming keys in the C<%^H>,
1161 documented under L<Key naming|perlpragma/Key naming>.
1165 =head3 L<perlsec/Laundering and Detecting Tainted Data>
1171 The example function for checking for taintedness contained a subtle
1172 error. C<$@> needs to be localized to prevent its changing this
1173 global's value outside the function. The preferred method to check for
1174 this remains L<Scalar::Util/tainted>.
1184 L<perllol> has been expanded with examples using the new C<push $scalar>
1185 syntax introduced in Perl 5.14.0 (5.14.1).
1195 L<perlmod> now states explicitly that some types of explicit symbol table
1196 manipulation are not supported. This codifies what was effectively already
1197 the case [perl #78074].
1201 =head3 L<perlpodstyle>
1207 The tips on which formatting codes to use have been corrected and greatly
1212 There are now a couple of example one-liners for previewing POD files after
1213 they have been edited.
1223 The C<(*COMMIT)> directive is now listed in the right section
1224 (L<Verbs without an argument|perlre/Verbs without an argument>).
1234 L<perlrun> has undergone a significant clean-up. Most notably, the
1235 B<-0x...> form of the B<-0> flag has been clarified, and the final section
1236 on environment variables has been corrected and expanded (5.14.1).
1246 The L<perlsub/"Lvalue subroutines"> section has been amended to reflect
1247 the many changes present in 5.16.0.
1251 The ($;) prototype syntax, which has existed for rather a long time, is now
1252 documented in L<perlsub>. It allows a unary function to have the same
1253 precedence as a list operator.
1263 Documented the required syntax for tying handles.
1273 The documentation for L<$!|perlvar/$!> has been corrected and clarified.
1274 It used to state that $! could be C<undef>, which is not the case. It was
1275 also unclear as to whether system calls set C's C<errno> or Perl's C<$!>
1280 Documentation for L<$$|perlvar/$$> has been amended with additional
1281 cautions regarding changing the process ID.
1285 =head3 Other Changes
1291 L<perlxs> was extended with documentation on inline typemaps.
1295 L<perlref> has a new L<Circular References|perlref/Circular References>
1296 section explaining how circularities may not be freed and how to solve that
1297 with weak references.
1301 Parts of L<perlapi> were clarified, and Perl equivalents of some C
1302 functions have been added as an additional mode of exposition.
1306 A few parts of L<perlre> and L<perlrecharclass> were clarified.
1310 =head2 Removed Documentation
1312 =head3 Old OO Documentation
1314 All the old OO tutorials, perltoot, perltooc, and perlboot, have been
1315 removed. The perlbot (bag of object tricks) document has been removed
1318 =head3 Development Deltas
1320 The perldelta files for development releases are no longer packaged with
1321 perl. These can still be found in the perl source code repository.
1325 The following additions or changes have been made to diagnostic output,
1326 including warnings and fatal error messages. For the complete list of
1327 diagnostic messages, see L<perldiag>.
1329 =head2 New Diagnostics
1337 L<Cannot set tied @DB::args|perldiag/"Cannot set tied @DB::args">
1339 This error occurs when C<caller> tries to set C<@DB::args> but finds it
1340 tied. Before this error was added, it used to crash instead.
1344 L<Cannot tie unreifiable array|perldiag/"Cannot tie unreifiable array">
1346 This error is part of a safety check that the C<tie> operator does before
1347 tying a special array like C<@_>. You should never see this message.
1351 L<Source filters apply only to byte streams|perldiag/"Source filters apply only to byte streams">
1353 This new error occurs when you try to activate a source filter (usually by
1354 loading a source filter module) within a string passed to C<eval> under the
1355 C<unicode_eval> feature.
1359 L<&CORE::%s cannot be called directly|perldiag/"&CORE::%s cannot be called directly">
1361 (F) You tried to call a subroutine in the C<CORE::> namespace
1362 with C<&foo> syntax or through a reference. The subroutines
1363 in this package cannot yet be called that way, but must be
1364 called as barewords. Something like this will work:
1366 BEGIN { *shove = \&CORE::push; }
1367 shove @array, 1,2,3; # pushes on to @array
1377 L<defined(@array) is deprecated|perldiag/"defined(@array) is deprecated">
1379 The long-deprecated C<defined(@array)> now also warns for package variables.
1380 Previously it only issued a warning for lexical variables.
1384 L<Useless use of \E|perldiag/"Useless use of \E">
1386 C<\E> does nothing unless preceded by C<\Q>, C<\L> or C<\U>.
1390 L<overload arg '%s' is invalid|perldiag/"overload arg '%s' is invalid">
1392 This warning, in the "overload" category, is produced when the overload
1393 pragma is given an argument it doesn't recognize, presumably a mistyped
1398 L<Useless assignment to a temporary|perldiag/"Useless assignment to a temporary">
1400 Assigning to a temporary returned from an XS lvalue subroutine now produces a
1401 warning [perl #31946].
1405 L<length() used on %s|perldiag/length() used on %s>
1407 This new warning occurs when C<length> is used on an array or hash, instead
1408 of C<scalar(@array)> or C<scalar(keys %hash)>.
1412 L<$[ used in %s (did you mean $] ?)|perldiag/"$[ used in %s (did you mean $] ?)">
1414 This new warning exists to catch the mistaken use of C<$[> in version
1415 checks. C<$]>, not C<$[>, contains the version number. C<$[> in a numeric
1416 comparison is almost always wrong.
1420 L<Use of assignment to $[ is deprecated|perldiag/"Use of assignment to $[ is deprecated">
1422 This previously removed warning has been restored with the re-implementation
1423 of C<$[> as a module.
1427 =head2 Removed Warnings
1433 "sort is now a reserved word"
1435 This error used to occur when C<sort> was called without arguments,
1436 followed by C<;> or C<)>. (E.g., C<sort;> would die, but C<{sort}> was
1437 OK.) This error message was added in Perl 3 to catch code like
1438 C<close(sort)> which would no longer work. More than two decades later,
1439 this message is no longer appropriate. Now C<sort> without arguments is
1440 always allowed, and returns an empty list, as it did in those cases
1441 where it was already allowed [perl #90030].
1445 =head2 Changes to Existing Diagnostics
1451 Redefinition warnings for constant subroutines used to be mandatory,
1452 even occurring under C<no warnings>. Now they respect the L<warnings>
1457 The "Attempt to free non-existent shared string" has had the spelling
1458 of "non-existent" corrected to "nonexistent". It was already listed
1459 with the correct spelling in L<perldiag>.
1463 The 'Use of "foo" without parentheses is ambiguous' warning has been
1464 extended to apply also to user-defined subroutines with a (;$)
1465 prototype, and not just to built-in functions.
1469 The error messages for using C<default> and C<when> outside of a
1470 topicalizer have been standardised to match the messages for C<continue>
1471 and loop controls. They now read 'Can't "default" outside a
1472 topicalizer' and 'Can't "when" outside a topicalizer'. They both used
1473 to be 'Can't use when() outside a topicalizer' [perl #91514].
1477 The uninitialized warning for C<y///r> when C<$_> is implicit and
1478 undefined now mentions the variable name, just like the non-/r variation
1483 The "Applying pattern match..." or similar warning produced when an
1484 array or hash is on the left-hand side of the C<=~> operator now
1485 mentions the name of the variable.
1489 The L<Invalid version format|perldiag/"Invalid version format (%s)">
1490 error message now says "negative version number" within the parentheses,
1491 rather than "non-numeric data", for negative numbers.
1496 L<Possible attempt to put comments in qw() list|perldiag/"Possible attempt to put comments in qw() list">
1498 L<Possible attempt to separate words with commas|perldiag/"Possible attempt to separate words with commas">
1499 are no longer mutually exclusive: the same C<qw> construct may produce
1504 The message, "Code point 0x%X is not Unicode, no properties match it;
1505 all inverse prop erties do" has been changed to "Code point 0x%X is not
1506 Unicode, all \p{} matches fail; all \P{} matches succeed"
1510 Warnings that mention the names of lexical (C<my>) variables with
1511 Unicode characters in them now respect the presence or absence of the
1512 C<:utf8> layer on the output handle, instead of outputting UTF8
1513 regardless. Also, the correct names are included in the strings passed
1514 to C<$SIG{__WARN__}> handlers, rather than the raw UTF8 bytes.
1518 =head1 Utility Changes
1526 L<h2ph> used to generate code of the form
1528 unless(defined(&FOO)) {
1532 But the subroutine is a compile-time declaration, and is hence unaffected
1533 by the condition. It has now been corrected to emit a string C<eval>
1534 around the subroutine [perl #99368].
1544 F<splain> no longer emits backtraces with the first line number repeated.
1548 Uncaught exception from user code:
1549 Cannot fwiddle the fwuddle at -e line 1.
1551 main::baz() called at -e line 1
1552 main::bar() called at -e line 1
1553 main::foo() called at -e line 1
1557 Uncaught exception from user code:
1558 Cannot fwiddle the fwuddle at -e line 1.
1559 main::baz() called at -e line 1
1560 main::bar() called at -e line 1
1561 main::foo() called at -e line 1
1565 Some error messages consist of multiple lines that are listed as separate
1566 entries in L<perldiag>. splain has been taught to find the separate
1567 entries in these cases, instead of simply failing to find the message.
1571 =head3 L<zipdetails>
1577 L<zipdetails> displays information about the internal record structure
1578 of the zip file. It is not concerned with displaying any details of
1579 the compressed data stored in the zip file.
1583 =head1 Configuration and Compilation
1589 The C<-Dusesitecustomize> and C<-Duserelocatableinc> options now work
1594 F<regexp.h> has been modified for compatibility with GCC's B<-Werror>
1595 option, as used by some projects that include perl's header files (5.14.1).
1599 C<USE_LOCALE{,_COLLATE,_CTYPE,_NUMERIC}> have been added the output of perl -V
1600 as they have affect the behaviour of the interpreter binary (albeit only
1605 The code and tests for L<IPC::Open2> have been moved from F<ext/IPC-Open2>
1606 into F<ext/IPC-Open3>, as C<IPC::Open2::open2()> is implemented as a thin
1607 wrapper around C<IPC::Open3::_open3()>, and hence is very tightly coupled to
1612 The magic types and magic vtables are now generated from data in a new script
1613 F<regen/mg_vtable.pl>, instead of being maintained by hand. As different EBCDIC
1614 variants can't agree on the code point for '~', the character to code point
1615 conversion is done at build time by F<generate_uudmap> to a new generated header
1616 F<mg_data.h>. C<PL_vtbl_bm> and C<PL_vtbl_fm> are now defined by the
1617 pre-processor as C<PL_vtbl_regexp>, instead of being distinct C variables.
1618 C<PL_vtbl_sig> has been removed.
1622 Building with C<-DPERL_GLOBAL_STRUCT> works again. This configuration is not
1627 Perl configured with I<MAD> now correctly frees C<MADPROP> structures when
1628 OPs are freed. C<MADPROP>s are now allocated with C<PerlMemShared_malloc()>
1634 XXX Any significant changes to the testing of a freshly built perl should be
1635 listed here. Changes which create B<new> files in F<t/> go here as do any
1636 large changes to the testing harness (e.g. when parallel testing was added).
1637 Changes to existing files in F<t/> aren't worth summarising, although the bugs
1638 that they represent may be covered elsewhere.
1640 [ List each test improvement as a =item entry ]
1650 =head1 Platform Support
1652 XXX Any changes to platform support should be listed in the sections below.
1654 [ Within the sections, list each platform as a =item entry with specific
1655 changes as paragraphs below it. ]
1657 =head2 New Platforms
1659 XXX List any platforms that this version of perl compiles on, that previous
1660 versions did not. These will either be enabled by new files in the F<hints/>
1661 directories, or new subdirectories and F<README> files at the top level of the
1666 =item XXX-some-platform
1672 =head2 Discontinued Platforms
1674 XXX List any platforms that this version of perl no longer compiles on.
1678 =item XXX-some-platform
1684 =head2 Platform-Specific Notes
1692 Since version 1.7, Cygwin supports native UTF-8 paths. If Perl is built
1693 under that environment, directory and filenames will be UTF-8 encoded.
1695 Cygwin does not initialize all original Win32 environment variables. See
1696 F<README.cygwin> for a discussion of C<Cygwin::sync_winenv()> and
1707 Remove unnecessary includes, fix miscellaneous compiler warnings and
1708 close some unclosed comments on F<vms/vms.c>.
1710 Remove sockadapt layer from the VMS build.
1714 Explicit support for VMS versions prior to v7.0 and DEC C versions
1715 prior to v6.0 has been removed.
1719 Since Perl 5.10.1, the home-grown C<stat> wrapper has been unable to
1720 distinguish between a directory name containing an underscore and an
1721 otherwise-identical filename containing a dot in the same position
1722 (e.g., t/test_pl as a directory and t/test.pl as a file). This problem
1727 The build on VMS now allows names of the resulting symbols in C code for
1728 Perl longer than 31 characters. Symbols like
1729 C<Perl__it_was_the_best_of_times_it_was_the_worst_of_times> can now be
1730 created freely without causing the VMS linker to seize up.
1736 Numerous build and test failures on GNU/Hurd have been resolved with hints
1737 for building DBM modules, detection of the library search path, and enabling
1738 of large file support.
1742 Perl is now built with dynamic linking on OpenVOS, the minimum supported
1743 version of which is now Release 17.1.0.
1747 The CC workshop C++ compiler is now detected and used on systems that ship
1750 =head1 Internal Changes
1756 There are now feature bundle hints in C<PL_hints> (C<$^H>) that version
1757 declarations use, to avoid having to load F<feature.pm>. One setting of
1758 the hint bits indicates a "custom" feature bundle, which means that the
1759 entries in C<%^H> still apply. F<feature.pm> uses that.
1761 The C<HINT_FEATURE_MASK> macro is defined in F<perl.h> along with other
1762 hints. Other macros for setting and testing features and bundles are in
1763 the new F<feature.h>. C<FEATURE_IS_ENABLED> (which has moved to
1764 F<feature.h>) is no longer used throughout the codebase, but more specific
1765 macros, e.g., C<FEATURE_SAY_IS_ENABLED>, that are defined in F<feature.h>.
1769 F<lib/feature.pm> is now a generated file, created by the new
1770 F<regen/feature.pl> script, which also generates F<feature.h>.
1774 Tied arrays are now always C<AvREAL>. If C<@_> or C<DB::args> is tied, it
1775 is reified first, to make sure this is always the case.
1779 The C<is_gv_magical_sv> function has been eliminated and merged with
1780 C<gv_fetchpvn_flags>. It used to be called to determine whether a GV
1781 should be autovivified in rvalue context. Now it has been replaced with a
1782 new C<GV_ADDMG> flag (not part of the API).
1786 Padlists are now marked C<AvREAL>; i.e., reference-counted. They have
1787 always been reference-counted, but were not marked real, because F<pad.c>
1788 did its own clean-up, instead of using the usual clean-up code in F<sv.c>.
1789 That caused problems in thread cloning, so now the C<AvREAL> flag is on,
1790 but is turned off in F<pad.c> right before the padlist is freed (after
1791 F<pad.c> has done its custom freeing of the pads).
1795 All the C files that make up the Perl core have been converted to UTF-8.
1799 =head1 Selected Bug Fixes
1801 =head2 Regular expressions and character classes
1807 C</[[:ascii:]]/> and C</[[:blank:]]/> now use locale rules under
1808 C<use locale> when the platform supports that. Previously, they used
1809 the platform's native character set.
1813 C</.*/g> would sometimes refuse to match at the end of a string that ends
1814 with "\n". This has been fixed [perl #109206].
1818 C<m/[[:ascii:]]/i> and C</\p{ASCII}/i> now match identically (when not
1819 under a differing locale). This fixes a regression introduced in 5.14
1820 in which the first expression could match characters outside of ASCII,
1821 such as the KELVIN SIGN.
1825 Starting with 5.12.0, Perl used to get its internal bookkeeping muddled up
1826 after assigning C<${ qr// }> to a hash element and locking it with
1827 L<Hash::Util>. This could result in double frees, crashes or erratic
1832 The new (in 5.14.0) regular expression modifier C</a> when repeated like
1833 C</aa> forbids the characters outside the ASCII range that match
1834 characters inside that range from matching under C</i>. This did not
1835 work under some circumstances, all involving alternation, such as:
1837 "\N{KELVIN SIGN}" =~ /k|foo/iaa;
1839 succeeded inappropriately. This is now fixed.
1843 5.14.0 introduced some memory leaks in regular expression character
1844 classes such as C<[\w\s]>, which have now been fixed (5.14.1)
1848 An edge case in regular expression matching could potentially loop.
1849 This happened only under C</i> in bracketed character classes that have
1850 characters with multi-character folds, and the target string to match
1851 against includes the first portion of the fold, followed by another
1852 character that has a multi-character fold that begins with the remaining
1853 portion of the fold, plus some more.
1855 "s\N{U+DF}" =~ /[\x{DF}foo]/i
1857 is one such case. C<\xDF> folds to C<"ss">. (5.14.1)
1861 A few characters in regular expression pattern matches did not
1862 match correctly in some circumstances, all involving C</i>. The
1863 affected characters are:
1864 COMBINING GREEK YPOGEGRAMMENI,
1865 GREEK CAPITAL LETTER IOTA,
1866 GREEK CAPITAL LETTER UPSILON,
1867 GREEK PROSGEGRAMMENI,
1868 GREEK SMALL LETTER IOTA WITH DIALYTIKA AND OXIA,
1869 GREEK SMALL LETTER IOTA WITH DIALYTIKA AND TONOS,
1870 GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND OXIA,
1871 GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND TONOS,
1872 LATIN SMALL LETTER LONG S,
1873 LATIN SMALL LIGATURE LONG S T,
1875 LATIN SMALL LIGATURE ST.
1879 Fixed memory leak regression in regular expression compilation
1884 A regression introduced in 5.13.6 was fixed. This involved an inverted
1885 bracketed character class in a regular expression that consisted solely
1886 of a Unicode property, that property wasn't getting inverted outside the
1897 A number of edge cases have been fixed with formats and C<formline>;
1898 in particular, where the format itself is potentially variable (such as
1899 with ties and overloading), and where the format and data differ in their
1900 encoding. In both these cases, it used to possible for the output to be
1901 corrupted [perl #91032].
1905 C<formline> no longer converts its argument into a string in-place. So
1906 passing a reference to C<formline> no longer destroys the reference
1911 =head2 Copy-on-write scalars
1913 Copy-on-write scalars were introduced in 5.8.0, but most Perl code
1914 did not encounter them (they were used mostly internally). Perl
1915 5.10.0 extended them, such that assigning C<__PACKAGE__> or a
1916 hash key to a scalar would make it copy-on-write. Several parts
1917 of Perl were not updated to account for them, but have now been fixed.
1923 C<utf8::decode> had a nasty bug that would modify copy-on-write scalars'
1924 string buffers in place (i.e., skipping the copy). This could result in
1925 hashes having two elements with the same key [perl #91834].
1929 Lvalue subroutines were not allowing COW scalars to be returned. This was
1930 fixed for lvalue scalar context in Perl 5.12.3 and 5.14.0, but list context
1931 was not fixed until this release.
1935 Elements of restricted hashes (see the L<fields> pragma) containing
1936 copy-on-write values couldn't be deleted, nor could such hashes be cleared
1941 Localising a tied variable used to make it read-only if it contained a
1942 copy-on-write string.
1946 L<Storable>, L<Devel::Peek> and L<PerlIO::scalar> had similar problems.
1947 See L</Updated Modules and Pragmata>, above.
1951 =head2 lvalue subroutines
1953 There have been various fixes to lvalue subroutines.
1959 Explicit return now returns the actual argument passed to return, instead
1960 of copying it [perl #72724] [perl #72706].
1962 B<Note:> There are still some discrepancies between explicit and implicit
1963 return, which will hopefully be resolved soon. So the exact behaviour is
1964 not set in stone yet.
1968 Lvalue subroutines used to enforce lvalue syntax (i.e., whatever can go on
1969 the left-hand side of C<=>) for the last statement and the arguments to
1970 return. Since lvalue subroutines are not always called in lvalue context,
1971 this restriction has been lifted.
1975 Lvalue subroutines are less restrictive as to what values can be returned.
1976 It used to croak on values returned by C<shift> and C<delete> and from
1977 other subroutines, but no longer does so [perl #71172].
1981 Empty lvalue subroutines (C<sub :lvalue {}>) used to return C<@_> in list
1982 context. In fact, all subroutines used to, but regular subs were fixed in
1983 Perl 5.8.2. Now lvalue subroutines have been likewise fixed.
1987 Lvalue subroutines used to copy their return values in rvalue context. Not
1988 only was this a waste of CPU cycles, but it also caused bugs. A C<($)>
1989 prototype would cause an lvalue sub to copy its return value [perl #51408],
1990 and C<while(lvalue_sub() =~ m/.../g) { ... }> would loop endlessly
1995 Autovivification now works on values returned from lvalue subroutines
2000 When called in pass-by-reference context (e.g., subroutine arguments or a list
2001 passed to C<for>), an lvalue subroutine returning arrays or hashes used to bind
2002 the arrays (or hashes) to scalar variables--something that is not supposed to
2003 happen. This could result in "Bizarre copy of ARRAY" errors or C<print>
2004 ignoring its arguments. It also made nonsensical code like C<@{\$_}> "work".
2005 This was fixed in 5.14.0 if an array were the first thing returned from the
2006 subroutine (but not for C<$scalar, @array> or hashes being returned). Now a
2007 more general fix has been applied [perl #23790].
2011 When called in pass-by-reference context, lvalue subroutines used to copy
2012 any read-only value that was returned. E.g., C< sub :lvalue { $] } >
2013 would not return C<$]>, but a copy of it.
2017 Assignment to C<keys> returned from an lvalue sub used not to work, but now
2022 Applying the C<:lvalue> attribute to an XSUB or to an aliased subroutine
2023 stub with C<< sub foo :lvalue; >> syntax stopped working in Perl 5.12.
2024 This has been fixed.
2028 Method calls whose arguments were all surrounded with C<my()> or C<our()>
2029 (as in C<< $object->method(my($a,$b)) >>) used to force lvalue context on
2030 the subroutine. This would prevent lvalue methods from returning certain
2035 =head2 Fixes related to hashes
2041 A bug has been fixed that would cause a "Use of freed value in iteration"
2042 error if the next two hash elements that would be iterated over are
2043 deleted [perl #85026]. (5.14.1)
2047 Freeing deeply nested hashes no longer crashes [perl #44225].
2051 Deleting the current hash iterator (the hash element that would be returend
2052 by the next call to C<each>) in void context used not to free it. The hash
2053 would continue to reference it until the next iteration. This has been
2054 fixed [perl #85026].
2058 =head2 Support for Embedded Nulls
2060 Some parts of Perl did not work correctly with nulls (C<chr 0>) embedded in
2061 strings. That meant that, for instance, C<< $m = "a\0b"; foo->$m >> would
2062 call the "a" method, instead of the actual method name contained in $m.
2063 These parts of perl have been fixed to support nulls:
2073 Typeglob names (including filehandle names)
2085 Return value of C<ref()>
2089 Package names returned by C<caller()>
2097 Typeglob elements (C<*foo{"THING\0stuff"}>)
2105 Various warnings and error messages that mention variable names or values,
2110 One side effect of these changes is that blessing into "\0" no longer
2111 causes C<ref()> to return false.
2113 =head2 Other notable fixes
2119 Last-accessed filehandle
2121 Perl has an internal variable that stores the last filehandle to be
2122 accessed. It is used by C<$.> and by C<tell> and C<eof> without
2125 It used to be possible to set this internal variable to a glob copy and
2126 then modify that glob copy to be something other than a glob, and still
2127 have the last-accessed filehandle associated with the variable after
2128 assigning a glob to it again:
2130 my $foo = *STDOUT; # $foo is a glob copy
2131 <$foo>; # $foo is now the last-accessed handle
2132 $foo = 3; # no longer a glob
2133 $foo = *STDERR; # still the last-accessed handle
2135 Now the C<$foo = 3> assignment unsets that internal variable, so there
2136 is no last-accessed filehandle, just as if C<< <$foo> >> had never
2141 C<stat _> no longer warns about unopened filehandles [perl #71002].
2145 C<stat> on an unopened filehandle now warns consistently, instead of
2146 skipping the warning at times.
2150 C<-t> now works when stacked with other filetest operators [perl #77388].
2154 Stacked filetest operators now only call FETCH once on a tied argument.
2158 C<~~> now correctly handles the precedence of Any~~Object, and is not tricked
2159 by an overloaded object on the left-hand side.
2165 Tying C<%^H> no longer causes perl to crash or ignore the contents of
2166 C<%^H> when entering a compilation scope [perl #106282].
2170 C<quotemeta> now quotes consistently the same non-ASCII characters under
2171 C<use feature 'unicode_strings'>, regardless of whether the string is
2172 encoded in UTF-8 or not, hence fixing the last vestiges (we hope) of the
2173 infamous L<perlunicode/The "Unicode Bug">. [perl #77654].
2175 Which of these code points is quoted has changed, based on Unicode's
2176 recommendations. See L<perlfunc/quotemeta> for details.
2182 The bitwise complement operator (and possibly other operators, too) when
2183 passed a vstring would leave vstring magic attached to the return value,
2184 even though the string had changed. This meant that
2185 C<< version->new(~v1.2.3) >> would create a version looking like "v1.2.3"
2186 even though the string passed to C<< version->new >> was actually
2187 "\376\375\374". This also caused L<B::Deparse> to deparse C<~v1.2.3>
2188 incorrectly, without the C<~> [perl #29070].
2192 Vstrings blowing away magic
2194 Assigning a vstring to a magic (e.g., tied, C<$!>) variable and then
2195 assigning something else used to blow away all the magic. This meant that
2196 tied variables would come undone, C<$!> would stop getting updated on
2197 failed system calls, C<$|> would stop setting autoflush, and other
2198 mischief would take place. This has been fixed.
2202 C<newHVhv> and tied hashes
2204 The C<newHVhv> XS function now works on tied hashes, instead of crashing or
2205 returning an empty hash.
2209 Hashes will null elements
2211 It is possible from XS code to create hashes with elements that have no
2212 values. Perl itself sometimes creates such hashes, but they are rarely
2213 visible to Perl code. The hash element and slice operators used to crash
2214 when handling these in lvalue context. These have been fixed. They now
2215 produce a "Modification of non-creatable hash value attempted" error
2220 No warning for C<open(foo::bar)>
2222 When one writes C<open foo || die>, which used to work in Perl 4, a
2223 "Precedence problem" warning is produced. This warning used erroneously to
2224 apply to fully-qualified bareword handle names not followed by C<||>. This
2229 C<select> and package aliasing
2231 After package aliasing (C<*foo:: = *bar::>), C<select> with 0 or 1 argument
2232 would sometimes return a name that could not be used to refer to the
2233 filehandle, or sometimes it would return C<undef> even when a filehandle
2234 was selected. Now it returns a typeglob reference in such cases.
2238 C<PerlIO::get_layers> and tied variables
2240 C<PerlIO::get_layers> no longer ignores FETCH on tied variables as it used
2241 to most of the time [perl #97956].
2245 C<PerlIO::get_layers> and numbers
2247 C<PerlIO::get_layers> no longer ignores some arguments that it thinks are
2248 numeric, while treating others as filehandle names. It is now consistent
2249 for flat scalars (i.e., not references).
2253 Lvalue subs and strict mode
2255 Lvalue sub calls that are not determined to be such at compile time
2256 (C<&$name> or &{"name"}) are no longer exempt from strict refs if they
2257 occur in the last statement of an lvalue subroutine [perl #102486].
2261 Non-lvalue sub calls in potentially lvalue context
2263 Sub calls whose subs are not visible at compile time, if
2264 they occurred in the last statement of an lvalue subroutine,
2265 would reject non-lvalue subroutines and die with "Can't modify non-lvalue
2266 subroutine call" [perl #102486].
2268 Non-lvalue sub calls whose subs I<are> visible at compile time exhibited
2269 the opposite bug. If the call occurred in the last statement of an lvalue
2270 subroutine, there would be no error when the lvalue sub was called in
2271 lvalue context. Perl would blindly assign to the temporary value returned
2272 by the non-lvalue subroutine.
2276 AUTOLOADing lvalue subs
2278 C<AUTOLOAD> routines used to take precedence over the actual sub being
2279 called (i.e., when autoloading wasn't needed), for sub calls in lvalue or
2280 potential lvalue context, if the subroutine was not visible at compile
2285 C<caller> and tied C<@DB::args>
2287 C<caller> sets C<@DB::args> to the subroutine arguments when called from
2288 the DB package. It used to crash when doing so if C<@DB::args> happened to
2289 be tied. Now it croaks instead.
2295 Under debugging builds, this code:
2297 sub TIEARRAY{bless[]}
2303 use to produce an "av_reify called on tied array" warning. It doesn't any
2308 Unrecognised switches on C<#!> line
2310 If a switch, such as B<-x>, that cannot occur on the C<#!> line is used
2311 there, perl dies with "Can't emulate...".
2313 It used to produce the same message for switches that perl did not
2314 recognise at all, whether on the command line or the C<#!> line.
2316 Now it produces the "Unrecognized switch" error message [perl #104288].
2320 C<system> and SIGCHLD
2322 C<system> now temporarily blocks the SIGCHLD signal handler, to prevent the
2323 signal handler from stealing the exit status [perl #105700].
2327 Deleting methods via C<delete>
2329 Deletion of methods via C<delete $Class::{method}> syntax used to update
2330 method caches if called in void context, but not scalar or list context.
2331 Now it always updates those caches.
2335 Hash element deletion and destructors
2337 When hash elements are deleted in void context, the internal hash entry is
2338 now freed before the value is freed, to prevent destructors called by that
2339 latter freeing from seeing the hash in an inconsistent state. It was
2340 possible to cause double-frees if the destructor freed the hash itself
2345 C<(s)printf>'s %n formatting code
2347 The %n formatting code, which causes the number of characters to be
2348 assigned to the next argument to C<printf> or C<sprintf> now actually
2349 assigns the number of characters, instead of the number of bytes.
2351 It also works now with special lvalue functions like C<substr> and with
2352 nonexistent hash and array elements [perl #3471, #103492].
2356 Typeglobs and threads
2358 Typeglobs returned from threads are no longer cloned if the parent thread
2359 already has a glob with the same name. This means that returned
2360 subroutines will now assign to the right package variables [perl #107366].
2366 In Perl 5.14, C<local $_> was changed to create a new variable not tied to
2367 anything, even if $_ was tied before that. But, due to an oversight, it
2368 would still call FETCH once on a tied $_ before replacing it with the new
2369 variable. This has been fixed [perl #105912].
2373 Returning tied variables
2375 When returning a value from a non-lvalue subroutine, Perl copies the value.
2376 Sometimes it cheats for the sake of speed, and does not copy the value if
2377 it makes no observable difference. This optimisation was erroneously
2378 allowing the copy to be skipped on tied variables, causing a difference in
2379 behaviour depending on the tied variable's reference count. This has been
2380 fixed [perl #95548].
2384 C<utf8::decode> now refuses to modify read-only scalars [perl #91850].
2388 C<dbmopen> with undefined mode
2390 C<dbmopen> now only warns once, rather than three times, if the mode
2391 argument is C<undef> [perl #90064].
2395 Freeing an aggregate during list assignment
2397 If list assignment to a hash or array triggered destructors that freed the
2398 hash or array itself, a crash would ensue. This is no longer the case
2403 Confused internal bookkeeping with @ISA arrays
2405 Creating a weak reference to an @ISA array or accessing the array index
2406 (C<$#ISA>) could result in confused internal bookkeeping for elements
2407 subsequently added to the @ISA array. For instance, creating a weak
2408 reference to the element itself could push that weak reference on to @ISA;
2409 and elements added after use of C<$#ISA> would be ignored by method lookup
2414 DELETE on scalar ties
2416 Tying an element of %ENV or C<%^H> and then deleting that element would
2417 result in a call to the tie object's DELETE method, even though tying the
2418 element itself is supposed to be equivalent to tying a scalar (the element
2419 is, of course, a scalar) [perl #67490].
2423 Freeing $_ inside C<grep> or C<map>
2425 Freeing $_ inside a C<grep> or C<map> block or a code block embedded in a
2426 regular expression used to result in double frees [perl #92254, #92256].
2432 The C<+=> operator does not usually warn when the left-hand side is
2433 C<undef>, but it was doing so for tied variables. This has been fixed
2438 Tying and autovivification
2440 When Perl autovivifies an element of a tied array or hash (which entails
2441 calling STORE with a new reference), it now calls FETCH immediately after
2442 the STORE, instead of assuming that FETCH would have returned the same
2443 reference. This can make it easier to implement tied objects [perl #35865, #43011].
2449 Mentioning a variable named "&" other than C<$&> (i.e., C<@&> or C<%&>) no
2450 longer stops C<$&> from working. The same applies to variables named "'"
2451 and "`" [perl #24237].
2457 C<-T> and C<-B> now work when stacked up with other filetest operators
2462 Filetests and stat buffers
2464 Perl keeps several internal variables to keep track of the last stat
2465 buffer, from which file(handle) it originated, what type it was, and
2466 whether the last stat succeeded.
2468 There were various cases where these could get out of synch, resulting in
2469 inconsistent or erratic behaviour in edge cases (every mention of C<-T>
2470 applies to C<-B> as well):
2476 C<-T I<HANDLE>>, even though it does a C<stat>, was not resetting the last
2477 stat type, so an C<lstat _> following it would merrily return the wrong
2478 results. Also, it was not setting the success status.
2482 Freeing the handle last used by C<stat> or a filetest could result in
2483 S<C<-T _>> using an unrelated handle.
2487 C<stat> with an IO reference (as returned by C<*STDIO{IO}>, for instance)
2488 would not reset the stat type.
2492 C<stat> with an IO reference was not recording the filehandle for
2497 The presence of fatal warnings could cause the stat buffer not to be reset
2498 for a filetest operator on an unopened filehandle or C<-l> on any handle.
2502 Fatal warnings would stop C<-T> from setting C<$!>.
2506 When the last stat was on an unreadable file, C<-T _> is supposed to
2507 return C<undef>, leaving the last stat buffer unchanged. But it was
2508 setting the stat type, causing C<lstat _> to stop working.
2512 C<-T I<FILENAME>> was not resetting the internal stat buffers for
2517 These have all been fixed.
2521 C<-T _> with no preceding C<stat>
2523 This used to produce a confusing "uninitialized" warning, even though there
2524 is no visible uninitialized value to speak of.
2528 C<stat I<HANDLE>> and fstat failures
2530 If the operating system's C<fstat> function failed, C<stat> would warn
2531 about an unopened handle, even though that was not the case. This has been
2538 C<lstat> is documented to fall back to C<stat> (with a warning) when given
2539 a filehandle. When passed an IO reference, it was actually doing the
2540 equivalent of S<C<stat _>> and ignoring the handle.
2544 Bitwise assignment operators and copy-on-write
2546 In 5.14.0, the bitwise assignment operators C<|=>, C<^=> and C<&=> started
2547 leaving the left-hand side undefined if it happened to be a copy-on-write
2548 string. This has been fixed [perl #108480].
2552 Three problematic Unicode characters now work better in regex pattern matching under C</i>
2554 In the past, three Unicode characters:
2555 LATIN SMALL LETTER SHARP S,
2556 GREEK SMALL LETTER IOTA WITH DIALYTIKA AND TONOS,
2558 GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND TONOS,
2559 along with the sequences that they fold to
2560 (including "ss" in the case of LATIN SMALL LETTER SHARP S),
2561 did not properly match under C</i>. 5.14.0 fixed some of these cases,
2562 but introduced others, including a panic when one of the characters or
2563 sequences was used in the C<(?(DEFINE)> regular expression predicate.
2564 The known bugs that were introduced in 5.14 have now been fixed; as well
2565 as some other edge cases that have never worked until now. All these
2566 involve using the characters and sequences outside bracketed character
2567 classes under C</i>. This closes [perl #98546].
2569 There remain known problems when using certain characters with
2570 multi-character folds inside bracketed character classes, including such
2571 constructs as C<qr/[\N{LATIN SMALL LETTER SHARP}a-z]/i>. These
2572 remaining bugs are addressed in [perl #89774].
2576 RT #78266: The regex engine has been leaking memory when accessing
2577 named captures that weren't matched as part of a regex ever since 5.10
2578 when they were introduced, e.g. this would consume over a hundred MB of
2581 for (1..10_000_000) {
2582 if ("foo" =~ /(foo|(?<capture>bar))?/) {
2583 my $capture = $+{capture}
2586 system "ps -o rss $$"'
2590 A constant subroutine assigned to a glob whose name contains a null
2591 will no longer cause extra globs to pop into existence when the
2592 constant is referenced under its new name.
2596 C<sort> was not treating C<sub {}> and C<sub {()}> as equivalent when
2597 such a sub was provided as the comparison routine. It used to croak on
2602 Subroutines from the C<autouse> namespace are once more exempt from
2603 redefinition warnings. This used to work in 5.005, but was broken in
2604 5.6 for most subroutines. For subs created via XS that redefine
2605 subroutines from the C<autouse> package, this stopped working in 5.10.
2609 New XSUBs now produce redefinition warnings if they overwrite existing
2610 subs, as they did in 5.8.x. (The C<autouse> logic was reversed in
2611 5.10-14. Only subroutines from the C<autouse> namespace would warn
2616 C<newCONSTSUB> used to use compile-time warning hints, instead of
2617 run-time hints. The following code should never produce a redefinition
2618 warning, but it used to, if C<newCONSTSUB> redefined an existing
2624 some_XS_function_that_calls_new_CONSTSUB();
2629 Redefinition warnings for constant subroutines are on by default (what
2630 are known as severe warnings in L<perldiag>). This was only the case
2631 when it was a glob assignment or declaration of a Perl subroutine that
2632 caused the warning. If the creation of XSUBs triggered the warning, it
2633 was not a default warning. This has been corrected.
2637 The internal check to see whether a redefinition warning should occur
2638 used to emit "uninitialized" warnings in cases like this:
2640 use warnings "uninitialized";
2641 use constant {u => undef, v => undef};
2647 A bug fix in Perl 5.14 introduced a new bug, causing "uninitialized"
2648 warnings to report the wrong variable if the operator in question had
2649 two operands and one was C<%{...}> or C<@{...}>. This has been fixed
2654 C<< version->new("version") >> and C<printf "%vd", "version"> no longer
2655 crash [perl #102586].
2659 C<$tied =~ y/a/b/>, C<chop $tied> and C<chomp $tied> now call FETCH
2660 just once when $tied holds a reference.
2664 Four-argument C<select> now always calls FETCH on tied arguments. It
2665 used to skip the call if the tied argument happened to hold C<undef> or
2670 Four-argument C<select> no longer produces its "Non-string passed as
2671 bitmask" warning on tied or tainted variables that are strings.
2675 C<sysread> now always calls FETCH on the buffer passed to it if the
2676 buffer is tied. It used to skip the call if the tied variable happened
2681 C<< $tied .= <> >> now calls FETCH once on C<$tied>. It used to call
2682 it multiple times if the last value assigned to or returned from the
2683 tied variable was anything other than a string or typeglob.
2687 Return value of C<eval>
2689 C<eval> returns C<undef> in scalar context or an empty list in list
2690 context when there is a run-time error. When C<eval> was passed a
2691 string in list context and a syntax error occurred, it used to return a
2692 list containing a single undefined element. Now it returns an empty
2693 list in list context for all errors [perl #80630].
2697 C<goto &func> no longer crashes, but produces an error message, when
2698 the unwinding of the current subroutine's scope fires a destructor that
2699 undefines the subroutine being "goneto" [perl #99850].
2703 Arithmetic assignment (C<$left += $right>) involving overloaded objects
2704 that rely on the 'nomethod' override no longer segfault when the left
2705 operand is not overloaded.
2709 Assigning C<__PACKAGE__> or any other shared hash key scalar to a stash
2710 element no longer causes a double free. Regardless of this change, the
2711 results of such assignments are still undefined.
2715 Assigning C<__PACKAGE__> or another shared hash key string to a
2716 variable no longer stops that variable from being tied if it happens to
2717 be a PVMG or PVLV internally.
2721 Creating a C<UNIVERSAL::AUTOLOAD> sub no longer stops C<%+>, C<%-> and
2722 C<%!> from working some of the time [perl #105024].
2726 When presented with malformed UTF-8 input, the XS-callable functions
2727 C<is_utf8_string()>, C<is_utf8_string_loc()>, and
2728 C<is_utf8_string_loclen()> could read beyond the end of the input
2729 string by up to 12 bytes. This no longer happens. [perl #32080].
2730 However, currently, C<is_utf8_char()> still has this defect, see
2731 L</is_utf8_char()> above.
2735 Doing a substitution on a tied variable returning a copy-on-write
2736 scalar used to cause an assertion failure or an "Attempt to free
2737 nonexistent shared string" warning.
2741 The debugger no longer tries to do C<local $_> when dumping data
2746 Calling C<readline($fh)> where $fh is a glob copy (e.g., after C<$fh =
2747 *STDOUT>), assigning something other than a glob to $fh, and then
2748 freeing $fh (e.g., by leaving the scope where it is defined) no longer
2749 causes the internal variable used by C<$.> (C<PL_last_in_gv>) to point
2750 to a freed scalar, that could be reused for some other glob, causing
2751 C<$.> to use some unrelated filehandle [perl #97988].
2755 A regression in 5.14 caused these statements not to set the internal
2756 variable that holds the handle used by C<$.>:
2767 This is now fixed, but C<tell *{ *$fh }> still has the problem, and it
2768 is not clear how to fix it [perl #106536].
2772 Version comparisons, such as those that happen implicitly with C<use
2773 v5.43>, no longer cause locale settings to change [perl #105784].
2777 Perl now holds an extra reference count on the package that code is
2778 currently compiling in. This means that the following code no longer crashes [perl #101486]:
2781 BEGIN {*Foo:: = *Bar::}
2786 F<dumpvar.pl>, and consequently the C<x> command in the debugger, have been
2787 fixed to handle objects blessed into classes whose names contain "=". The
2788 contents of such objects used not to be dumped [perl #101814].
2792 The C<x> repetition operator no longer crashes on 64-bit builds with large
2793 repeat counts [perl #94560].
2797 On OSes other than VMS, Perl's C<glob> operator (and the C<< <...> >> form)
2798 use L<File::Glob> underneath. L<File::Glob> splits the pattern into words,
2799 before feeding each word to its C<bsd_glob> function.
2801 There were several inconsistencies in the way the split was done. Now
2802 quotation marks (' and ") are always treated as shell-style word delimiters
2803 (that allow whitespace as part of a word) and backslashes are always
2804 preserved, unless they exist to escape quotation marks. Before, those
2805 would only sometimes be the case, depending on whether the pattern
2806 contained whitespace. Also, escaped whitespace at the end of the pattern
2807 is no longer stripped [perl #40470].
2811 C<CORE::glob> now works as a way to call the default globbing function. It
2812 used to respect overrides, despite the C<CORE::> prefix.
2816 In 5.14, C</[[:lower:]]/i> and C</[[:upper:]]/i> no longer matched the
2817 opposite case. This has been fixed [perl #101970].
2821 A regular expression match with an overloaded object on the right-hand side
2822 would in some cases stringify the object too many times.
2826 The C-level C<pregcomp> function could become confused as to whether the
2827 pattern was in UTF8 if the pattern was an overloaded, tied, or otherwise
2828 magical scalar [perl #101940].
2832 A regression has been fixed that was introduced in 5.14, in C</i>
2833 regular expression matching, in which a match improperly fails if the
2834 pattern is in UTF-8, the target string is not, and a Latin-1 character
2835 precedes a character in the string that should match the pattern. [perl
2840 Weak references to lexical hashes going out of scope were not going stale
2841 (becoming undefined), but continued to point to the hash.
2845 Weak references to lexical variables going out of scope are now broken
2846 before any magical methods (e.g., DESTROY on a tie object) are called.
2847 This prevents such methods from modifying the variable that will be seen
2848 the next time the scope is entered.
2852 A C<keys> optimisation in Perl 5.12.0 to make it faster on empty hashes
2853 caused C<each> not to reset the iterator if called after the last element
2854 was deleted. This has been fixed.
2858 The C<#line 42 foo> directive used not to update the arrays of lines used
2859 by the debugger if it occurred in a string eval. This was partially fixed
2860 in 5.14, but it only worked for a single C<#line 42 foo> in each eval. Now
2861 it works for multiple.
2865 String eval used not to localise C<%^H> when compiling its argument if it
2866 was empty at the time the C<eval> call itself was compiled. This could
2867 lead to scary side effects, like C<use re "/m"> enabling other flags that
2868 the surrounding code was trying to enable for its caller [perl #68750].
2872 Creating a BEGIN block from XS code (via C<newXS> or C<newATTRSUB>) would,
2873 on completion, make the hints of the current compiling code the current
2874 hints. This could cause warnings to occur in a non-warning scope.
2878 C<eval $string> and C<require> no longer localise hints (C<$^H> and C<%^H>)
2879 at run time, but only during compilation of the $string or required file.
2880 This makes C<BEGIN { $^H{foo}=7 }> equivalent to
2881 C<BEGIN { eval '$^H{foo}=7' }> [perl #70151].
2885 When subroutine calls are intercepted by the debugger, the name of the
2886 subroutine or a reference to it is stored in C<$DB::sub>, for the debugger
2887 to access. In some cases (such as C<$foo = *bar; undef *bar; &$foo>)
2888 C<$DB::sub> would be set to a name that could not be used to find the
2889 subroutine, and so the debugger's attempt to call it would fail. Now the
2890 check to see whether a reference is needed is more robust, so those
2891 problems should not happen anymore [rt.cpan.org #69862].
2895 Localising a tied scalar that returns a typeglob no longer stops it from
2896 being tied till the end of the scope.
2900 When C<open> is called with three arguments, the third being a file handle
2901 (as in C<< open $fh, ">&", $fh2 >>), if the third argument is tied or a
2902 reference to a tied variable, FETCH is now called exactly once, instead of
2903 0, 2, or 3 times (all of which could occur in various circumstances).
2907 C<sort> no longer ignores FETCH when passed a reference to a tied glob for
2908 the comparison routine.
2912 Warnings emitted by C<sort> when a custom comparison routine returns a
2913 non-numeric value now show the line number of the C<sort> operator, rather
2914 than the last line of the comparison routine. The warnings also occur now
2915 only if warnings are enabled in the scope where C<sort> occurs. Previously
2916 the warnings would occur if enabled in the comparison routine's scope.
2920 C<Internals::SvREFCNT> now behaves consistently in 'get' and 'set' scenarios
2921 [perl #103222] and also treats the reference count as unsigned.
2925 Calling C<require> on an implicit C<$_> when C<*CORE::GLOBAL::require> has
2926 been overridden does not segfault anymore, and C<$_> is now passed to the
2927 overriding subroutine [perl #78260].
2931 In Perl 5.14.0, C<$tainted ~~ @array> stopped working properly. Sometimes
2932 it would erroneously fail (when C<$tainted> contained a string that occurs
2933 in the array I<after> the first element) or erroneously succeed (when
2934 C<undef> occurred after the first element) [perl #93590].
2938 Functions in the CORE package can now be called as methods. That used to
2939 work only when they had been called or referenced already. So
2940 C<< "foo"->CORE::ucfirst >> returns Foo.
2944 C<use> and C<require> are no longer affected by the I/O layers active in
2945 the caller's scope (enabled by L<open.pm|open>) [perl #96008].
2949 Errors that occur when methods cannot be found during overloading now
2950 mention the correct package name, as they did in 5.8.x, instead of
2951 erroneously mentioning the "overload" package, as they have since 5.10.0.
2955 Undefining C<%overload::> no longer causes a crash.
2959 C<our $::Ć©; $Ć©> (which is invalid) no longer produces the "Compilation
2960 error at lib/utf8_heavy.pl..." error message, which it started emitting in
2961 5.10.0 [perl #99984].
2965 In case-insensitive regular expression pattern matching, no longer on
2966 UTF-8 encoded strings does the scan for the start of match only look at
2967 the first possible position. This caused matches such as
2968 C<"f\x{FB00}" =~ /ff/i> to fail.
2972 On 64-bit systems, C<read()> now understands large string offsets beyond
2977 Errors that occur when processing subroutine attributes no longer cause the
2978 subroutine's op tree to leak.
2982 C<sort> now works once more with custom sort routines that are XSUBs. It
2983 stopped working in 5.10.0.
2987 C<sort> with a constant for a custom sort routine, although it produces
2988 unsorted results, no longer crashes. It started crashing in 5.10.0.
2992 Warnings produced when a custom sort routine returns a non-numeric value
2993 now contain "in sort"; e.g., "Use of uninitialized value in sort".
2997 C<< sort { $a <=> $b } >>, which is optimised internally, now produces
2998 "uninitialized" warnings for NaNs (not-a-number values), since C<< <=> >>
2999 returns C<undef> for those. This brings it in line with
3000 S<C<< sort { 1; $a <=> $b } >>> and other more complex cases, which are not
3001 optimised [perl #94390].
3005 C<..> and C<...> in list context now call FETCH only once on tied
3006 arguments, instead of three or four times [perl #53554].
3010 C<..> and C<...> in list context now mention the name of the variable in
3011 "uninitialized" warnings for string (as opposed to numeric) ranges.
3015 Passing the same constant subroutine to both C<index> and C<formline> no
3016 longer causes one or the other to fail [perl #89218]. (5.14.1)
3020 List assignment to lexical variables declared with attributes in the same
3021 statement (C<my ($x,@y) : blimp = (72,94)>) stopped working in Perl 5.8.0.
3022 It has now been fixed.
3026 Perl 5.10.0 introduced some faulty logic that made "U*" in the middle of
3027 a pack template equivalent to "U0" if the input string was empty. This has
3028 been fixed [perl #90160].
3032 Destructors on objects were not called during global destruction on objects
3033 that were not referenced by any scalars. This could happen if an array
3034 element were blessed (e.g., C<bless \$a[0]>) or if a closure referenced a
3035 blessed variable (C<bless \my @a; sub foo { @a }>).
3037 Now there is an extra pass during global destruction to fire destructors on
3038 any objects that might be left after the usual passes that check for
3039 objects referenced by scalars [perl #36347].
3041 This bug fix was added in Perl 5.13.9, but caused problems with some CPAN
3042 modules that were relying on the bug. Since it was so close to Perl
3043 5.14.0, the fix was reverted in 5.13.10, to allow more time for the modules
3044 to adapt. Hopefully they will be fixed soon (see L</Known Problems>,
3049 C<given> was not calling set-magic on the implicit lexical C<$_> that it
3050 uses. This meant, for example, that C<pos> would be remembered from one
3051 execution of the same C<given> block to the next, even if the input were a
3052 different variable [perl #84526].
3056 The "R" command for restarting a debugger session has been fixed to work on
3057 Windows, or any other system lacking a C<POSIX::_SC_OPEN_MAX> constant
3062 Fixed a case where it was possible that a freed buffer may have been read
3063 from when parsing a here document [perl #90128]. (5.14.1)
3067 The C<study> function could become confused if fed a string longer than
3068 2**31 characters. Now that it's a no-op, it can't.
3072 C<each(I<ARRAY>)> is now wrapped in C<defined(...)>, like C<each(I<HASH>)>,
3073 inside a C<while> condition [perl #90888].
3077 In @INC filters (subroutines returned by subroutines in @INC), $_ used to
3078 misbehave: If returned from a subroutine, it would not be copied, but the
3079 variable itself would be returned; and freeing $_ (e.g., with C<undef *_>)
3080 would cause perl to crash. This has been fixed [perl #91880].
3084 An ASCII single quote (') in a symbol name is meant to be equivalent to a
3085 double colon (::) except at the end of the name. It was not equivalent if
3086 followed by a null character, but now it is [perl #88138].
3090 The abbreviations for four C1 control characters C<MW> C<PM>, C<RI>, and
3091 C<ST> were previously unrecognized by C<\N{}>, vianame(), and
3096 Some cases of threads crashing due to memory allocation during cloning have
3097 been fixed [perl #90006].
3101 Attempting to C<goto> out of a tied handle method used to cause memory
3102 corruption or crashes. Now it produces an error message instead
3107 Perl skips copying values returned from a subroutine if it thinks the value
3108 is not in use elsewhere. Due to faulty logic, this would happen with the
3109 result of C<delete>, C<shift> or C<splice>, even if the result was
3110 referenced elsewhere. So C<< \sub { delete $_[0] }->($x) >> would return a
3111 reference to C<$x>. This has been fixed [perl #91844].
3115 Applying the :lvalue attribute to subroutine that is already defined does
3116 not work properly, as the attribute changes the way the sub is compiled.
3117 Hence, Perl 5.12 began warning when an attempt is made to apply the
3118 attribute to an already defined sub. In such cases, the attribute is
3121 But the change in 5.12 missed the case where custom attributes are also
3122 present: that case still silently and ineffectively applied the attribute.
3123 That omission has now been corrected. C<sub foo :lvalue :Whatever> (when
3124 C<foo> is already defined) now warns about the :lvalue attribute, and does
3127 L<attributes.pm|attributes> has likewise been updated to warn and not apply
3132 The remaining discrepancies between explicit and implicit return from
3133 lvalue subroutines have been resolved. They mainly involved which error
3134 message to display when a read-only value is returned in lvalue context.
3135 Also, returning a PADTMP (the result of most built-ins, like C<index>) in
3136 lvalue context is now forbidden for explicit return, as it always has been
3137 for implicit return. This is not a regression from 5.14, as all the cases
3138 in which it could happen where previously syntax errors.
3142 The C<prototype> function no longer dies for the C<__FILE__>, C<__LINE__>
3143 and C<__PACKAGE__> directives. It now returns an empty-string prototype
3144 for them, because they are syntactically very similar to nullary functions
3149 C<prototype> now returns C<undef> for all overridable infix operators,
3150 such as C<eq>, which are not callable in any way resembling functions.
3151 It used to return incorrect prototypes for some and die for others
3156 A bug affecting lvalue context propagation through nested lvalue subroutine
3157 calls has been fixed. Previously, returning a value in nested rvalue
3158 context would be treated as lvalue context by the inner subroutine call,
3159 resulting in some values (such as read-only values) being rejected.
3163 Some core bugs affecting L<Hash::Util> have been fixed: locking a hash
3164 element that is a glob copy no longer causes subsequent assignment to it to
3165 corrupt the glob, and unlocking a hash element that holds a copy-on-write
3166 scalar no longer causes modifications to that scalar to modify other
3167 scalars that were sharing the same string buffer.
3171 C<when> blocks are now capable of returning variables declared inside the
3172 enclosing C<given> block [perl #93548].
3176 A problem with context propagation when a C<do> block is an argument to
3177 C<return> has been fixed. It used to cause C<undef> to be returned in
3178 some cases of a C<return> inside an C<if> block which itself is followed by
3183 Calling C<index> with a tainted constant no longer causes constants in
3184 subsequently compiled code to become tainted [perl #64804].
3188 Use of lexical (C<my>) variables in code blocks embedded in regular
3189 expressions will no longer result in memory corruption or crashes.
3191 Nevertheless, these code blocks are still experimental, as there are still
3192 problems with the wrong variables being closed over (in loops for instance)
3193 and with abnormal exiting (e.g., C<die>) causing memory corruption.
3197 The C<SvIsCOW> C macro now returns false for read-only copies of typeglobs,
3198 such as those created by:
3201 Hash::Util::lock_value %hash, 'elem';
3203 It used to return true.
3207 Assignment to C<$^A> (the format output accumulator) now recalculates
3208 the number of lines output.
3212 The regexp optimiser no longer crashes on debugging builds when merging
3213 fixed-string nodes with inconvenient contents.
3217 Locking a subroutine (via C<lock &sub>) is no longer a compile-time error
3218 for regular subs. For lvalue subroutines, it no longer tries to return the
3219 sub as a scalar, resulting in strange side effects like C<ref \$_>
3220 returning "CODE" in some instances.
3222 C<lock &sub> is now a run-time error if L<threads::shared> is loaded (a
3223 no-op otherwise), but that may be rectified in a future version.
3227 The prototypes of several built-in functions--C<getprotobynumber>, C<lock>,
3228 C<not> and C<select>--have been corrected, or at least are now closer to
3229 reality than before.
3233 Most dereferencing operators (C<${}>, etc.) used to call C<FETCH> twice on
3234 a tied operand when doing a symbolic dereference (looking up a variable by
3235 name, which is not permitted under C<use strict 'refs'>). Only C<&{}> did
3236 not have this problem. This has been fixed.
3240 A panic involving the combination of the regular expression modifiers
3241 C</aa> and the C<\b> escape sequence introduced in 5.14.0 has been
3242 fixed [perl #95964].
3246 stat() would always return the inode number as an IV, even when the
3247 original was unsigned, or too large to fit in an IV. stat() now
3248 returns the inode number as the type that would best preserve the
3249 original value. [perl #84590]
3253 The combination of the regular expression modifiers C</aa> and the C<\b>
3254 and C<\B> escape sequences did not work properly on UTF-8 encoded
3255 strings. All non-ASCII characters under C</aa> should be treated as
3256 non-word characters, but what was happening was that Unicode rules were
3257 used to determine wordness/non-wordness for non-ASCII characters. This
3258 is now fixed [perl #95968].
3262 Infinite loops like C<1 while 1> used to stop C<strict 'subs'> mode from
3263 working for the rest of the block.t
3267 The C<\h>, C<\H>, C<\v> and C<\V> regular expression metacharacters used to
3268 cause a panic error message when attempting to match at the end of the
3269 string [perl #96354].
3273 For list assignments like C<($a,$b) = ($b,$a)>, Perl has to make a copy of
3274 the items on the right-hand side before assignment them to the left. For
3275 efficiency's sake, it assigns the values on the right straight to the items
3276 on the left no variable is mentioned on both sides, as in
3277 C<($a,$b) = ($c,$d)>. The logic for determining when it can cheat was
3278 faulty, in that C<&&> and C<||> on the right-hand side could fool it. So
3279 C<($a,$b) = $some_true_value && ($b,$a)> would end up assigning the value
3280 of C<$b> to both scalars.
3284 Perl no longer tries to apply lvalue context to the string in
3285 C<("string", $variable) ||= 1> (which used to be an error). Since the
3286 left-hand side of C<||=> is evaluated in scalar context, that's a scalar
3287 comma operator, which gives all but the last item void context. There is
3288 no such thing as void lvalue context, so it was a mistake for Perl to try
3289 to force it [perl #96942].
3293 Every subroutine has a filename associated with it, that the debugger uses.
3294 The one associated with constant subroutines used to be misallocated when
3295 cloned under threads. Consequently, debugging threaded applications could
3296 result in memory corruption [perl #96126].
3300 C<caller> no longer leaks memory when called from the DB package if
3301 C<@DB::args> was assigned to after the first call to C<caller>. L<Carp>
3302 was triggering this bug [perl #97010].
3306 C<defined(${"..."})>, C<defined(*{"..."})>, etc., used to
3307 return true for most, but not all built-in variables, if
3308 they had not been used yet. Many times that new built-in
3309 variables were added in past versions, this construct was
3310 not taken into account, so this affected C<${^GLOBAL_PHASE}> and
3311 C<${^UTF8CACHE}>, among others. It also used to return false if the
3312 package name was given as well (C<${"::!"}>) and for subroutines in the
3313 CORE package [perl #97978] [perl #97492] [perl #97484].
3317 Perl 5.10.0 introduced a similar bug: C<defined(*{"foo"})> where "foo"
3318 represents the name of a built-in global variable used to return false if
3319 the variable had never been used before, but only on the I<first> call.
3320 This, too, has been fixed.
3324 Various functions that take a filehandle argument in rvalue context
3325 (C<close>, C<readline>, etc.) used to call C<FETCH> multiple times, if it
3326 was a tied variable, and warn twice, if it was C<undef> [perl #97482].
3330 C<close> and similar filehandle functions, when called on built-in global
3331 variables (like C<$+>), used to die if the variable happened to hold the
3332 undefined value, instead of producing the usual "Use of uninitialized
3337 When autovivified file handles were introduced in Perl 5.6.0, C<readline>
3338 was inadvertently made to autovivify when called as C<readline($foo)> (but
3339 not as C<E<lt>$fooE<gt>>). It has now been fixed never to autovivify.
3343 C<defined ${ $tied_variable }> used to call C<FETCH> multiple times, but
3344 now calls it just once.
3348 Some cases of dereferencing a complex expression, such as
3349 C<${ (), $tied } = 1>, used to call C<FETCH> multiple times, but now call
3354 For a tied variable returning a package name, C<$tied-E<gt>method> used to
3355 call C<FETCH> multiple times (even up to six!), and sometimes would
3356 fail to call the method, due to memory corruption.
3360 Calling an undefined anonymous subroutine (e.g., what $x holds after
3361 C<undef &{$x = sub{}}>) used to cause a "Not a CODE reference" error, which
3362 has been corrected to "Undefined subroutine called" [perl #71154].
3366 Causing C<@DB::args> to be freed between uses of C<caller> no longer
3367 results in a crash [perl #93320].
3371 Since 5.6.0, C<*{ ... }> has been inconsistent in how it treats undefined
3372 values. It would die in strict mode or lvalue context for most undefined
3373 values, but would be treated as the empty string (with a warning) for the
3374 specific scalar return by C<undef()> (C<&PL_sv_undef> internally). This
3375 has been corrected. C<undef()> is now treated like other undefined
3376 scalars, as in Perl 5.005.
3380 It used to be possible to free the typeglob of a localised array or hash
3381 (e.g., C<local @{"x"}; delete $::{x}>), resulting in a crash on scope exit.
3385 C<setpgrp($foo)> used to be equivalent to C<($foo, setpgrp)>, because
3386 C<setpgrp> was ignoring its argument if there was just one. Now it is
3387 equivalent to C<setpgrp($foo,0)>.
3391 Assignments like C<*$tied = \&{"..."}> and C<*glob = $tied> now call FETCH
3396 C<chdir>, C<chmod>, C<chown>, C<utime>, C<truncate>, C<stat>, C<lstat> and
3397 the filetest ops (C<-r>, C<-x>, etc.) now always call FETCH if passed a tied
3398 variable as the last argument. They used to ignore tiedness if the last
3399 thing return from or assigned to the variable was a typeglob or reference
3404 If things were arranged in memory the right way, it was possible for
3405 thread joining to emit "Attempt to free unreferenced scalar" warnings if
3406 C<caller> had been used from the C<DB> package prior to thread creation,
3407 due to the way pads were reference-counted and cloned [perl #98092].
3411 CORE:: subs were introduced in the previous development release, but
3412 C<defined &{"CORE::..."}> did not return true. That has been rectified
3417 A bug has been fixed that occurs when a tied variable is used as a
3418 subroutine reference: if the last thing assigned to or returned from the
3419 variable was a reference or typeglob, the C<\&$tied> could either crash or
3420 return the wrong subroutine. The reference case is a regression introduced
3421 in Perl 5.10.0. For typeglobs, it has probably never worked till now.
3425 C<given> was not scoping its implicit $_ properly, resulting in memory
3426 leaks or "Variable is not available" warnings [perl #94682].
3430 C<-l> followed by a bareword no longer "eats" the previous argument to
3431 the list operator in whose argument list it resides. In less convoluted
3432 English: C<print "bar", -l foo> now actually prints "bar", because C<-l>
3437 In 5.14.0, filetest ops (C<-r>, C<-x>, etc.) started calling FETCH on a
3438 tied argument belonging to the previous argument to a list operator, if
3439 called with a bareword argument or no argument at all. This has been
3440 fixed, so C<push @foo, $tied, -r> no longer calls FETCH on C<$tied>.
3444 C<shmread> was not setting the scalar flags correctly when reading from
3445 shared memory, causing the existing cached numeric representation in the
3446 scalar to persist [perl #98480].
3450 Weakening the first argument to an automatically-invoked C<DESTROY> method
3451 could result in erroneous "DESTROY created new reference" errors or
3452 crashes. Now it is an error to weaken a read-only reference.
3456 Under miniperl (used to configure modules when perl itself is built),
3457 C<glob> now clears %ENV before calling csh, since the latter croaks on some
3458 systems if it does not like the contents of the LS_COLORS enviroment
3459 variable [perl #98662].
3463 C<++> and C<--> now work on copies of globs, instead of dying.
3467 The subroutines in the CORE:: namespace that were introduced in the
3468 previous development release run with the lexical hints (strict, warnings)
3469 of the caller, just as though the built-in function had been called. But
3470 this was not the case for C<goto &CORE::sub>. The CORE sub would end up
3471 running with the lexical hints of the subroutine it replaced, instead of
3472 that subroutine's caller. This has been fixed.
3476 Stacked C<-l> (followed immediately by other filetest operators) did not
3477 work previously; now it does. It is only permitted when the rightmost
3478 filetest op has the special "_" handle for its argument and the most
3479 recent C<stat>/C<lstat> call was an C<lstat>.
3483 In Perl 5.6, C<-l> followed by anything other than a bareword would treat
3484 its argument as a file name. That was changed in 5.8 for glob references
3485 (C<\*foo>), but not for globs themselves (C<*foo>). C<-l> started
3486 returning C<undef> for glob references without setting the last
3487 stat buffer that the "_" handle uses, but only if warnings
3488 were turned on. With warnings off, it was the same as 5.6.
3489 In other words, it was simply buggy and inconsistent. Now the 5.6
3490 behaviour has been restored.
3494 C<splice()> doesn't warn when truncating
3496 You can now limit the size of an array using C<splice(@a,MAX_LEN)> without
3497 worrying about warnings.
3501 The C<SvPVutf8> C function no longer tries to modify its argument,
3502 resulting in errors [perl #108994].
3506 C<SvPVutf8> now works properly with magical variables.
3510 C<SvPVbyte> now works properly non-PVs.
3514 =head1 Known Problems
3520 We have a failing test in F<op/sigdispatch.t> on i386-netbsd 3.1
3524 On Solaris, we have two kinds of failure.
3526 If F<make> is Sun's F<makeā„>, we get an error about a badly formed macro
3527 assignment in the F<Makefile>. That happens when F<./Configure> tries to
3528 make depends. F<Configure> then exits 0, but further F<make>-ing fails.
3530 If F<make> is F<gmake>, F<Configure> completes, then we get errors related
3531 to F</usr/include/stdbool.h>
3537 XXX If any significant core contributor has died, we've added a short obituary
3540 =head1 Acknowledgements
3542 XXX Generate this with:
3544 perl Porting/acknowledgements.pl v5.14.0..HEAD
3546 =head1 Reporting Bugs
3548 If you find what you think is a bug, you might check the articles
3549 recently posted to the comp.lang.perl.misc newsgroup and the perl
3550 bug database at L<http://rt.perl.org/perlbug/>. There may also be
3551 information at L<http://www.perl.org/>, the Perl Home Page.
3553 If you believe you have an unreported bug, please run the L<perlbug>
3554 program included with your release. Be sure to trim your bug down
3555 to a tiny but sufficient test case. Your bug report, along with the
3556 output of C<perl -V>, will be sent off to perlbug@perl.org to be
3557 analysed by the Perl porting team.
3559 If the bug you are reporting has security implications, which make it
3560 inappropriate to send to a publicly archived mailing list, then please
3561 send it to perl5-security-report@perl.org. This points to a closed
3562 subscription unarchived mailing list, which includes all the core
3563 committers, who will be able to help assess the impact of issues, figure
3564 out a resolution, and help co-ordinate the release of patches to
3565 mitigate or fix the problem across all platforms on which Perl is
3566 supported. Please only use this address for security issues in the Perl
3567 core, not for modules independently distributed on CPAN.
3571 The F<Changes> file for an explanation of how to view exhaustive details
3574 The F<INSTALL> file for how to build Perl.
3576 The F<README> file for general stuff.
3578 The F<Artistic> and F<Copying> files for copyright information.