=head1 Notice
-XXX Any important notices here
+As described in L<perlpolicy>, the release of Perl 5.16.0 marks the
+official end of support for Perl 5.12. Users of Perl 5.12 or earlier
+should consider upgrading to a more recent release of Perl.
=head1 Core Enhancements
=head3 C<substr> lvalue revamp
-=for comment Can this be compacted some? -- rjbs, 2012-02-20
+=for comment Does this belong here, or under Incomptable Changes?
When C<substr> is called in lvalue or potential lvalue context with two
or three arguments, a special lvalue scalar is returned that modifies
looked at by C<substr> itself, but only when the returned lvalue is
read or modified.
-These changes result in several incompatible changes and bug fixes:
-
-=over
-
-=item *
+These changes result in an incompatible change:
If the original string changes length after the call to C<substr> but
before assignment to its return value, negative offsets will remember
lvalue will always extend to the end of the string, even if the string
becomes longer.
-=item *
-
-Tied (and otherwise magical) variables are no longer exempt from the
-"Attempt to use reference as lvalue in substr" warning.
-
-=item *
-
-That warning now occurs when the returned lvalue is assigned to, not
-when C<substr> itself is called. This only makes a difference if the
-return value of C<substr> is referenced and assigned to later.
-
-=item *
-
-The order in which "uninitialized" warnings occur for arguments to
-C<substr> has changed.
-
-=item *
-
-Passing a substring of a read-only value or a typeglob to a function
-(potential lvalue context) no longer causes an immediate "Can't coerce"
-or "Modification of a read-only value" error. That error only occurs
-if and when the value passed is assigned to.
-
-The same thing happens with the "substr outside of string" error. If
-the lvalue is only read, not written to, it is now just a warning, as
-with rvalue C<substr>.
-
-=item *
-
-C<substr> assignments no longer call FETCH twice if the first argument
-is a tied variable, just once.
-
-=back
-
-It was impossible to fix all the bugs without an incompatible change,
-and the behaviour of negative offsets was never specified, so the
+Since this change also allowed many bugs to be fixed (see
+L</Fixes to the C<substr> operator>), and since the behaviour
+of negative offsets has never been specified, so the
change was deemed acceptable.
=head3 Return value of C<tied>
=head1 Modules and Pragmata
-XXX All changes to installed files in F<cpan/>, F<dist/>, F<ext/> and F<lib/>
-go here. If Module::CoreList is updated, generate an initial draft of the
-following sections using F<Porting/corelist-perldelta.pl>, which prints stub
-entries to STDOUT. Results can be pasted in place of the '=head2' entries
-below. A paragraph summary for important changes should then be added by hand.
-In an ideal world, dual-life modules would have a F<Changes> file that could be
-cribbed.
-
-[ Within each section, list entries as a =item entry ]
-
=head2 Deprecated Modules
=over
=back
-=head1 Testing
-
-XXX Any significant changes to the testing of a freshly built perl should be
-listed here. Changes which create B<new> files in F<t/> go here as do any
-large changes to the testing harness (e.g. when parallel testing was added).
-Changes to existing files in F<t/> aren't worth summarising, although the bugs
-that they represent may be covered elsewhere.
-
-[ List each test improvement as a =item entry ]
-
-=over 4
-
-=item *
-
-XXX
-
-=back
-
=head1 Platform Support
-XXX Any changes to platform support should be listed in the sections below.
-
-[ Within the sections, list each platform as a =item entry with specific
-changes as paragraphs below it. ]
-
-=head2 New Platforms
-
-XXX List any platforms that this version of perl compiles on, that previous
-versions did not. These will either be enabled by new files in the F<hints/>
-directories, or new subdirectories and F<README> files at the top level of the
-source tree.
-
-=over 4
-
-=item XXX-some-platform
-
-XXX
-
-=back
-
-=head2 Discontinued Platforms
-
-XXX List any platforms that this version of perl no longer compiles on.
-
-=over 4
-
-=item XXX-some-platform
-
-XXX
-
-=back
-
=head2 Platform-Specific Notes
=head3 Cygwin
=head1 Selected Bug Fixes
-=head2 Regular expressions and character classes
-
-XXX Is it possible to merge some of these items?
+=head2 Array and hash
-=over 4
+=over
=item *
-C</[[:ascii:]]/> and C</[[:blank:]]/> now use locale rules under
-C<use locale> when the platform supports that. Previously, they used
-the platform's native character set.
+A bug has been fixed that would cause a "Use of freed value in iteration"
+error if the next two hash elements that would be iterated over are
+deleted [perl #85026]. (5.14.1)
=item *
-C<m/[[:ascii:]]/i> and C</\p{ASCII}/i> now match identically (when not
-under a differing locale). This fixes a regression introduced in 5.14
-in which the first expression could match characters outside of ASCII,
-such as the KELVIN SIGN.
+Deleting the current hash iterator (the hash element that would be returend
+by the next call to C<each>) in void context used not to free it
+[perl #85026].
=item *
-C</.*/g> would sometimes refuse to match at the end of a string that ends
-with "\n". This has been fixed [perl #109206].
+Deletion of methods via C<delete $Class::{method}> syntax used to update
+method caches if called in void context, but not scalar or list context.
=item *
-Starting with 5.12.0, Perl used to get its internal bookkeeping muddled up
-after assigning C<${ qr// }> to a hash element and locking it with
-L<Hash::Util>. This could result in double frees, crashes or erratic
-behaviour.
+When hash elements are deleted in void context, the internal hash entry is
+now freed before the value is freed, to prevent destructors called by that
+latter freeing from seeing the hash in an inconsistent state. It was
+possible to cause double-frees if the destructor freed the hash itself
+[perl #100340].
=item *
-The new (in 5.14.0) regular expression modifier C</a> when repeated like
-C</aa> forbids the characters outside the ASCII range that match
-characters inside that range from matching under C</i>. This did not
-work under some circumstances, all involving alternation, such as:
+A C<keys> optimisation in Perl 5.12.0 to make it faster on empty hashes
+caused C<each> not to reset the iterator if called after the last element
+was deleted.
- "\N{KELVIN SIGN}" =~ /k|foo/iaa;
+=item *
-succeeded inappropriately. This is now fixed.
+Freeing deeply nested hashes no longer crashes [perl #44225].
=item *
-5.14.0 introduced some memory leaks in regular expression character
-classes such as C<[\w\s]>, which have now been fixed. (5.14.1)
+It is possible from XS code to create hashes with elements that have no
+values. The hash element and slice operators used to crash
+when handling these in lvalue context. They now
+produce a "Modification of non-creatable hash value attempted" error
+message.
=item *
-An edge case in regular expression matching could potentially loop.
-This happened only under C</i> in bracketed character classes that have
-characters with multi-character folds, and the target string to match
-against includes the first portion of the fold, followed by another
-character that has a multi-character fold that begins with the remaining
-portion of the fold, plus some more.
+If list assignment to a hash or array triggered destructors that freed the
+hash or array itself, a crash would ensue. This is no longer the case
+[perl #107440].
- "s\N{U+DF}" =~ /[\x{DF}foo]/i
+=item *
-is one such case. C<\xDF> folds to C<"ss">. (5.14.1)
+It used to be possible to free the typeglob of a localised array or hash
+(e.g., C<local @{"x"}; delete $::{x}>), resulting in a crash on scope exit.
=item *
-A few characters in regular expression pattern matches did not
-match correctly in some circumstances, all involving C</i>. The
-affected characters are:
-COMBINING GREEK YPOGEGRAMMENI,
-GREEK CAPITAL LETTER IOTA,
-GREEK CAPITAL LETTER UPSILON,
-GREEK PROSGEGRAMMENI,
-GREEK SMALL LETTER IOTA WITH DIALYTIKA AND OXIA,
-GREEK SMALL LETTER IOTA WITH DIALYTIKA AND TONOS,
-GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND OXIA,
-GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND TONOS,
-LATIN SMALL LETTER LONG S,
-LATIN SMALL LIGATURE LONG S T,
-and
-LATIN SMALL LIGATURE ST.
+Some core bugs affecting L<Hash::Util> have been fixed: locking a hash
+element that is a glob copy no longer causes subsequent assignment to it to
+corrupt the glob, and unlocking a hash element that holds a copy-on-write
+scalar no longer causes modifications to that scalar to modify other
+scalars that were sharing the same string buffer.
-=item *
+=back
-A memory leak regression in regular expression compilation
-under threading has been fixed.
+=head2 C API fixes
+
+=over
=item *
-A regression introduced in 5.13.6 has
-been fixed. This involved an inverted
-bracketed character class in a regular expression that consisted solely
-of a Unicode property. That property wasn't getting inverted outside the
-Latin1 range.
+The C<newHVhv> XS function now works on tied hashes, instead of crashing or
+returning an empty hash.
=item *
-Three problematic Unicode characters now work better in regex pattern matching under C</i>
+The C<SvIsCOW> C macro now returns false for read-only copies of typeglobs,
+such as those created by:
-In the past, three Unicode characters:
-LATIN SMALL LETTER SHARP S,
-GREEK SMALL LETTER IOTA WITH DIALYTIKA AND TONOS,
-and
-GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND TONOS,
-along with the sequences that they fold to
-(including "ss" in the case of LATIN SMALL LETTER SHARP S),
-did not properly match under C</i>. 5.14.0 fixed some of these cases,
-but introduced others, including a panic when one of the characters or
-sequences was used in the C<(?(DEFINE)> regular expression predicate.
-The known bugs that were introduced in 5.14 have now been fixed; as well
-as some other edge cases that have never worked until now. All these
-involve using the characters and sequences outside bracketed character
-classes under C</i>. This closes [perl #98546].
+ $hash{elem} = *foo;
+ Hash::Util::lock_value %hash, 'elem';
-There remain known problems when using certain characters with
-multi-character folds inside bracketed character classes, including such
-constructs as C<qr/[\N{LATIN SMALL LETTER SHARP}a-z]/i>. These
-remaining bugs are addressed in [perl #89774].
+It used to return true.
=item *
-RT #78266: The regex engine has been leaking memory when accessing
-named captures that weren't matched as part of a regex ever since 5.10
-when they were introduced, e.g. this would consume over a hundred MB of
-memory:
-
- for (1..10_000_000) {
- if ("foo" =~ /(foo|(?<capture>bar))?/) {
- my $capture = $+{capture}
- }
- }
- system "ps -o rss $$"'
+The C<SvPVutf8> C function no longer tries to modify its argument,
+resulting in errors [perl #108994].
=item *
-In 5.14, C</[[:lower:]]/i> and C</[[:upper:]]/i> no longer matched the
-opposite case. This has been fixed [perl #101970].
+C<SvPVutf8> now works properly with magical variables.
=item *
-A regular expression match with an overloaded object on the right-hand side
-would in some cases stringify the object too many times.
+C<SvPVbyte> now works properly non-PVs.
=item *
-A regression has been fixed that was introduced in 5.14, in C</i>
-regular expression matching, in which a match improperly fails if the
-pattern is in UTF-8, the target string is not, and a Latin-1 character
-precedes a character in the string that should match the pattern.
-[perl #101710]
+When presented with malformed UTF-8 input, the XS-callable functions
+C<is_utf8_string()>, C<is_utf8_string_loc()>, and
+C<is_utf8_string_loclen()> could read beyond the end of the input
+string by up to 12 bytes. This no longer happens. [perl #32080].
+However, currently, C<is_utf8_char()> still has this defect, see
+L</is_utf8_char()> above.
=item *
-In case-insensitive regular expression pattern matching, no longer on
-UTF-8 encoded strings does the scan for the start of match only look at
-the first possible position. This caused matches such as
-C<"f\x{FB00}" =~ /ff/i> to fail.
-
-=item *
+The C-level C<pregcomp> function could become confused as to whether the
+pattern was in UTF8 if the pattern was an overloaded, tied, or otherwise
+magical scalar [perl #101940].
-The regexp optimiser no longer crashes on debugging builds when merging
-fixed-string nodes with inconvenient contents.
+=back
-=item *
+=head2 Compile-time hints
-A panic involving the combination of the regular expression modifiers
-C</aa> and the C<\b> escape sequence introduced in 5.14.0 has been
-fixed [perl #95964].
+=over
=item *
-The combination of the regular expression modifiers C</aa> and the C<\b>
-and C<\B> escape sequences did not work properly on UTF-8 encoded
-strings. All non-ASCII characters under C</aa> should be treated as
-non-word characters, but what was happening was that Unicode rules were
-used to determine wordness/non-wordness for non-ASCII characters. This
-is now fixed [perl #95968].
+Tying C<%^H> no longer causes perl to crash or ignore the contents of
+C<%^H> when entering a compilation scope [perl #106282].
=item *
-C<< (?foo: ...) >> no longer loses passed in character set.
+C<eval $string> and C<require> used not to
+localise C<%^H> during compilation if it
+was empty at the time the C<eval> call itself was compiled. This could
+lead to scary side effects, like C<use re "/m"> enabling other flags that
+the surrounding code was trying to enable for its caller [perl #68750].
=item *
-The trie optimisation used to have problems with alternations containing
-an empty C<(?:)>, causing C<< "x" =~ /\A(?>(?:(?:)A|B|C?x))\z/ >> not to
-match, whereas it should [perl #111842].
+C<eval $string> and C<require> no longer localise hints (C<$^H> and C<%^H>)
+at run time, but only during compilation of the $string or required file.
+This makes C<BEGIN { $^H{foo}=7 }> equivalent to
+C<BEGIN { eval '$^H{foo}=7' }> [perl #70151].
=item *
-Use of lexical (C<my>) variables in code blocks embedded in regular
-expressions will no longer result in memory corruption or crashes.
-
-Nevertheless, these code blocks are still experimental, as there are still
-problems with the wrong variables being closed over (in loops for instance)
-and with abnormal exiting (e.g., C<die>) causing memory corruption.
-
-=item *
-
-The C<\h>, C<\H>, C<\v> and C<\V> regular expression metacharacters used to
-cause a panic error message when attempting to match at the end of the
-string [perl #96354].
-
-=back
-
-=head2 Formats
-
-=over
-
-=item *
-
-A number of edge cases have been fixed with formats and C<formline>;
-in particular, where the format itself is potentially variable (such as
-with ties and overloading), and where the format and data differ in their
-encoding. In both these cases, it used to possible for the output to be
-corrupted [perl #91032].
-
-=item *
-
-C<formline> no longer converts its argument into a string in-place. So
-passing a reference to C<formline> no longer destroys the reference
-[perl #79532].
+Creating a BEGIN block from XS code (via C<newXS> or C<newATTRSUB>) would,
+on completion, make the hints of the current compiling code the current
+hints. This could cause warnings to occur in a non-warning scope.
=back
L<Storable>, L<Devel::Peek> and L<PerlIO::scalar> had similar problems.
See L</Updated Modules and Pragmata>, above.
-XXX That section is empty.
-
=back
-=head2 Lvalue subroutines
+=head2 The debugger
=over
=item *
-Explicit return now returns the actual argument passed to return, instead
-of copying it [perl #72724, #72706].
+F<dumpvar.pl>, and consequently the C<x> command in the debugger, have been
+fixed to handle objects blessed into classes whose names contain "=". The
+contents of such objects used not to be dumped [perl #101814].
=item *
-Lvalue subroutines used to enforce lvalue syntax (i.e., whatever can go on
-the left-hand side of C<=>) for the last statement and the arguments to
-return. Since lvalue subroutines are not always called in lvalue context,
-this restriction has been lifted.
+The "R" command for restarting a debugger session has been fixed to work on
+Windows, or any other system lacking a C<POSIX::_SC_OPEN_MAX> constant
+[perl #87740].
=item *
-Lvalue subroutines are less restrictive as to what values can be returned.
-It used to croak on values returned by C<shift> and C<delete> and from
-other subroutines, but no longer does so [perl #71172].
+The C<#line 42 foo> directive used not to update the arrays of lines used
+by the debugger if it occurred in a string eval. This was partially fixed
+in 5.14, but it only worked for a single C<#line 42 foo> in each eval. Now
+it works for multiple.
=item *
-Empty lvalue subroutines (C<sub :lvalue {}>) used to return C<@_> in list
-context. In fact, all subroutines used to, but regular subs were fixed in
-Perl 5.8.2. Now lvalue subroutines have been likewise fixed.
+When subroutine calls are intercepted by the debugger, the name of the
+subroutine or a reference to it is stored in C<$DB::sub>, for the debugger
+to access. In some cases (such as C<$foo = *bar; undef *bar; &$foo>)
+C<$DB::sub> would be set to a name that could not be used to find the
+subroutine, and so the debugger's attempt to call it would fail. Now the
+check to see whether a reference is needed is more robust, so those
+problems should not happen anymore [rt.cpan.org #69862].
=item *
-Autovivification now works on values returned from lvalue subroutines
-[perl #7946], as does returning C<keys> in lvalue context.
-
-=item *
+Every subroutine has a filename associated with it that the debugger uses.
+The one associated with constant subroutines used to be misallocated when
+cloned under threads. Consequently, debugging threaded applications could
+result in memory corruption [perl #96126].
-Lvalue subroutines used to copy their return values in rvalue context. Not
-only was this a waste of CPU cycles, but it also caused bugs. A C<($)>
-prototype would cause an lvalue sub to copy its return value [perl #51408],
-and C<while(lvalue_sub() =~ m/.../g) { ... }> would loop endlessly
-[perl #78680].
+=back
-=item *
+=head2 Dereferencing operators
-When called in potential lvalue context
-(e.g., subroutine arguments or a list
-passed to C<for>), lvalue subroutines used to copy
-any read-only value that was returned. E.g., C< sub :lvalue { $] } >
-would not return C<$]>, but a copy of it.
+=over
=item *
-When called in potential lvalue context, an lvalue subroutine returning
-arrays or hashes used to bind the arrays or hashes to scalar variables,
-resulting in bugs. This was fixed in 5.14.0 if an array were the first
-thing returned from the subroutine (but not for C<$scalar, @array> or
-hashes being returned). Now a more general fix has been applied
-[perl #23790].
+C<defined(${"..."})>, C<defined(*{"..."})>, etc., used to
+return true for most, but not all built-in variables, if
+they had not been used yet. This bug affected C<${^GLOBAL_PHASE}> and
+C<${^UTF8CACHE}>, among others. It also used to return false if the
+package name was given as well (C<${"::!"}>) [perl #97978, #97492].
=item *
-Method calls whose arguments were all surrounded with C<my()> or C<our()>
-(as in C<< $object->method(my($a,$b)) >>) used to force lvalue context on
-the subroutine. This would prevent lvalue methods from returning certain
-values.
+Perl 5.10.0 introduced a similar bug: C<defined(*{"foo"})> where "foo"
+represents the name of a built-in global variable used to return false if
+the variable had never been used before, but only on the I<first> call.
+This, too, has been fixed.
=item *
-Lvalue sub calls that are not determined to be such at compile time
-(C<&$name> or &{"name"}) are no longer exempt from strict refs if they
-occur in the last statement of an lvalue subroutine [perl #102486].
-
-=item *
+Since 5.6.0, C<*{ ... }> has been inconsistent in how it treats undefined
+values. It would die in strict mode or lvalue context for most undefined
+values, but would be treated as the empty string (with a warning) for the
+specific scalar return by C<undef()> (C<&PL_sv_undef> internally). This
+has been corrected. C<undef()> is now treated like other undefined
+scalars, as in Perl 5.005.
-Sub calls whose subs are not visible at compile time, if
-they occurred in the last statement of an lvalue subroutine,
-would reject non-lvalue subroutines and die with "Can't modify non-lvalue
-subroutine call" [perl #102486].
+=back
-Non-lvalue sub calls whose subs I<are> visible at compile time exhibited
-the opposite bug. If the call occurred in the last statement of an lvalue
-subroutine, there would be no error when the lvalue sub was called in
-lvalue context. Perl would blindly assign to the temporary value returned
-by the non-lvalue subroutine.
+=head2 Filehandle, last-accessed
-=item *
+Perl has an internal variable that stores the last filehandle to be
+accessed. It is used by C<$.> and by C<tell> and C<eof> without
+arguments.
-C<AUTOLOAD> routines used to take precedence over the actual sub being
-called (i.e., when autoloading wasn't needed), for sub calls in lvalue or
-potential lvalue context, if the subroutine was not visible at compile
-time.
+=over
=item *
-Applying the C<:lvalue> attribute to an XSUB or to an aliased subroutine
-stub with C<< sub foo :lvalue; >> syntax stopped working in Perl 5.12.
-This has been fixed.
+It used to be possible to set this internal variable to a glob copy and
+then modify that glob copy to be something other than a glob, and still
+have the last-accessed filehandle associated with the variable after
+assigning a glob to it again:
-=item *
+ my $foo = *STDOUT; # $foo is a glob copy
+ <$foo>; # $foo is now the last-accessed handle
+ $foo = 3; # no longer a glob
+ $foo = *STDERR; # still the last-accessed handle
-Applying the :lvalue attribute to subroutine that is already defined does
-not work properly, as the attribute changes the way the sub is compiled.
-Hence, Perl 5.12 began warning when an attempt is made to apply the
-attribute to an already defined sub. In such cases, the attribute is
-discarded.
+Now the C<$foo = 3> assignment unsets that internal variable, so there
+is no last-accessed filehandle, just as if C<< <$foo> >> had never
+happened.
-But the change in 5.12 missed the case where custom attributes are also
-present: that case still silently and ineffectively applied the attribute.
-That omission has now been corrected. C<sub foo :lvalue :Whatever> (when
-C<foo> is already defined) now warns about the :lvalue attribute, and does
-not apply it.
+This also prevents some unrelated handle from becoming the last-accessed
+handle if $foo falls out of scope and the same internal SV gets used for
+another handle [perl #97988].
=item *
-A bug affecting lvalue context propagation through nested lvalue subroutine
-calls has been fixed. Previously, returning a value in nested rvalue
-context would be treated as lvalue context by the inner subroutine call,
-resulting in some values (such as read-only values) being rejected.
+A regression in 5.14 caused these statements not to set that internal
+variable:
+
+ my $fh = *STDOUT;
+ tell $fh;
+ eof $fh;
+ seek $fh, 0,0;
+ tell *$fh;
+ eof *$fh;
+ seek *$fh, 0,0;
+ readline *$fh;
+
+This is now fixed, but C<tell *{ *$fh }> still has the problem, and it
+is not clear how to fix it [perl #106536].
=back
-=head2 Compile-time hints
+=head2 Filetests and C<stat>
+
+The term "filetests" refers to the operators that consist of a hyphen
+followed by a single letter: C<-r>, C<-x>, C<-M>, etc. The term "stacked"
+when applied to filetests means followed by another filetest operator
+sharing the same operand, as in C<-r -x -w $fooo>.
=over
=item *
-Tying C<%^H> no longer causes perl to crash or ignore the contents of
-C<%^H> when entering a compilation scope [perl #106282].
+C<stat> produces more consistent warnings. It no longer warns for "_"
+[perl #71002] and no longer skips the warning at times for other unopened
+handles. It no longer warns about an unopened handle when the operating
+system's C<fstat> function fails.
=item *
-C<eval $string> and C<require> used not to
-localise C<%^H> during compilation if it
-was empty at the time the C<eval> call itself was compiled. This could
-lead to scary side effects, like C<use re "/m"> enabling other flags that
-the surrounding code was trying to enable for its caller [perl #68750].
+C<stat> would sometimes return negative numbers for large inode numbers,
+because it was using the wrong internal C type. [perl #84590]
=item *
-C<eval $string> and C<require> no longer localise hints (C<$^H> and C<%^H>)
-at run time, but only during compilation of the $string or required file.
-This makes C<BEGIN { $^H{foo}=7 }> equivalent to
-C<BEGIN { eval '$^H{foo}=7' }> [perl #70151].
+C<lstat> is documented to fall back to C<stat> (with a warning) when given
+a filehandle. When passed an IO reference, it was actually doing the
+equivalent of S<C<stat _>> and ignoring the handle.
=item *
-Creating a BEGIN block from XS code (via C<newXS> or C<newATTRSUB>) would,
-on completion, make the hints of the current compiling code the current
-hints. This could cause warnings to occur in a non-warning scope.
-
-=back
-
-=head2 Fixes related to hashes and arrays
-
-=over
+C<-T _> with no preceding C<stat> used to produce a
+confusing "uninitialized" warning, even though there
+is no visible uninitialized value to speak of.
=item *
-A bug has been fixed that would cause a "Use of freed value in iteration"
-error if the next two hash elements that would be iterated over are
-deleted [perl #85026]. (5.14.1)
+C<-T>, C<-B>, C<-l> and C<-t> now work
+when stacked with other filetest operators
+[perl #77388].
=item *
-Deleting the current hash iterator (the hash element that would be returend
-by the next call to C<each>) in void context used not to free it
-[perl #85026].
+In 5.14.0, filetest ops (C<-r>, C<-x>, etc.) started calling FETCH on a
+tied argument belonging to the previous argument to a list operator, if
+called with a bareword argument or no argument at all. This has been
+fixed, so C<push @foo, $tied, -r> no longer calls FETCH on C<$tied>.
=item *
-Deletion of methods via C<delete $Class::{method}> syntax used to update
-method caches if called in void context, but not scalar or list context.
+In Perl 5.6, C<-l> followed by anything other than a bareword would treat
+its argument as a file name. That was changed in 5.8 for glob references
+(C<\*foo>), but not for globs themselves (C<*foo>). C<-l> started
+returning C<undef> for glob references without setting the last
+stat buffer that the "_" handle uses, but only if warnings
+were turned on. With warnings off, it was the same as 5.6.
+In other words, it was simply buggy and inconsistent. Now the 5.6
+behaviour has been restored.
=item *
-When hash elements are deleted in void context, the internal hash entry is
-now freed before the value is freed, to prevent destructors called by that
-latter freeing from seeing the hash in an inconsistent state. It was
-possible to cause double-frees if the destructor freed the hash itself
-[perl #100340].
+C<-l> followed by a bareword no longer "eats" the previous argument to
+the list operator in whose argument list it resides. Hence,
+C<print "bar", -l foo> now actually prints "bar", because C<-l>
+on longer eats it.
=item *
-A C<keys> optimisation in Perl 5.12.0 to make it faster on empty hashes
-caused C<each> not to reset the iterator if called after the last element
-was deleted.
+Perl keeps several internal variables to keep track of the last stat
+buffer, from which file(handle) it originated, what type it was, and
+whether the last stat succeeded.
-=item *
+There were various cases where these could get out of synch, resulting in
+inconsistent or erratic behaviour in edge cases (every mention of C<-T>
+applies to C<-B> as well):
-Freeing deeply nested hashes no longer crashes [perl #44225].
+=over
=item *
-It is possible from XS code to create hashes with elements that have no
-values. The hash element and slice operators used to crash
-when handling these in lvalue context. They now
-produce a "Modification of non-creatable hash value attempted" error
-message.
+C<-T I<HANDLE>>, even though it does a C<stat>, was not resetting the last
+stat type, so an C<lstat _> following it would merrily return the wrong
+results. Also, it was not setting the success status.
=item *
-If list assignment to a hash or array triggered destructors that freed the
-hash or array itself, a crash would ensue. This is no longer the case
-[perl #107440].
+Freeing the handle last used by C<stat> or a filetest could result in
+S<C<-T _>> using an unrelated handle.
=item *
-It used to be possible to free the typeglob of a localised array or hash
-(e.g., C<local @{"x"}; delete $::{x}>), resulting in a crash on scope exit.
+C<stat> with an IO reference would not reset the stat type or record the
+filehandle for S<C<-T _>> to use.
=item *
-Some core bugs affecting L<Hash::Util> have been fixed: locking a hash
-element that is a glob copy no longer causes subsequent assignment to it to
-corrupt the glob, and unlocking a hash element that holds a copy-on-write
-scalar no longer causes modifications to that scalar to modify other
-scalars that were sharing the same string buffer.
+Fatal warnings could cause the stat buffer not to be reset
+for a filetest operator on an unopened filehandle or C<-l> on any handle.
+Fatal warnings also stopped C<-T> from setting C<$!>.
+
+=item *
+
+When the last stat was on an unreadable file, C<-T _> is supposed to
+return C<undef>, leaving the last stat buffer unchanged. But it was
+setting the stat type, causing C<lstat _> to stop working.
+
+=item *
+
+C<-T I<FILENAME>> was not resetting the internal stat buffers for
+unreadable files.
=back
-=head2 Weak references
+These have all been fixed.
+
+=back
+
+=head2 Formats
=over
=item *
-Weakening the first argument to an automatically-invoked C<DESTROY> method
-could result in erroneous "DESTROY created new reference" errors or
-crashes. Now it is an error to weaken a read-only reference.
+A number of edge cases have been fixed with formats and C<formline>;
+in particular, where the format itself is potentially variable (such as
+with ties and overloading), and where the format and data differ in their
+encoding. In both these cases, it used to possible for the output to be
+corrupted [perl #91032].
=item *
-Weak references to lexical hashes going out of scope were not going stale
-(becoming undefined), but continued to point to the hash.
+C<formline> no longer converts its argument into a string in-place. So
+passing a reference to C<formline> no longer destroys the reference
+[perl #79532].
=item *
-Weak references to lexical variables going out of scope are now broken
-before any magical methods (e.g., DESTROY on a tie object) are called.
-This prevents such methods from modifying the variable that will be seen
-the next time the scope is entered.
+Assignment to C<$^A> (the format output accumulator) now recalculates
+the number of lines output.
+
+=back
+
+=head2 C<given> and C<when>
+
+=over
=item *
-Creating a weak reference to an @ISA array or accessing the array index
-(C<$#ISA>) could result in confused internal bookkeeping for elements
-subsequently added to the @ISA array. For instance, creating a weak
-reference to the element itself could push that weak reference on to @ISA;
-and elements added after use of C<$#ISA> would be ignored by method lookup
-[perl #85670].
+C<given> was not scoping its implicit $_ properly, resulting in memory
+leaks or "Variable is not available" warnings [perl #94682].
-=back
+=item *
-=head2 Support for embedded nulls
+C<given> was not calling set-magic on the implicit lexical C<$_> that it
+uses. This meant, for example, that C<pos> would be remembered from one
+execution of the same C<given> block to the next, even if the input were a
+different variable [perl #84526].
-Some parts of Perl did not work correctly with nulls (C<chr 0>) embedded in
-strings. That meant that, for instance, C<< $m = "a\0b"; foo->$m >> would
-call the "a" method, instead of the actual method name contained in $m.
-These parts of perl have been fixed to support nulls:
+=item *
+
+C<when> blocks are now capable of returning variables declared inside the
+enclosing C<given> block [perl #93548].
+
+=back
+
+=head2 The C<glob> operator
=over
=item *
-Method names
+On OSes other than VMS, Perl's C<glob> operator (and the C<< <...> >> form)
+use L<File::Glob> underneath. L<File::Glob> splits the pattern into words,
+before feeding each word to its C<bsd_glob> function.
+
+There were several inconsistencies in the way the split was done. Now
+quotation marks (' and ") are always treated as shell-style word delimiters
+(that allow whitespace as part of a word) and backslashes are always
+preserved, unless they exist to escape quotation marks. Before, those
+would only sometimes be the case, depending on whether the pattern
+contained whitespace. Also, escaped whitespace at the end of the pattern
+is no longer stripped [perl #40470].
=item *
-Typeglob names (including filehandle and subroutine names)
+C<CORE::glob> now works as a way to call the default globbing function. It
+used to respect overrides, despite the C<CORE::> prefix.
=item *
-Package names, including the return value of C<ref()>
+Under miniperl (used to configure modules when perl itself is built),
+C<glob> now clears %ENV before calling csh, since the latter croaks on some
+systems if it does not like the contents of the LS_COLORS enviroment
+variable [perl #98662].
+
+=back
+
+=head2 Lvalue subroutines
+
+=over
=item *
-Typeglob elements (C<*foo{"THING\0stuff"}>)
+Explicit return now returns the actual argument passed to return, instead
+of copying it [perl #72724, #72706].
=item *
-Signal names
+Lvalue subroutines used to enforce lvalue syntax (i.e., whatever can go on
+the left-hand side of C<=>) for the last statement and the arguments to
+return. Since lvalue subroutines are not always called in lvalue context,
+this restriction has been lifted.
=item *
-Various warnings and error messages that mention variable names or values,
-methods, etc.
+Lvalue subroutines are less restrictive as to what values can be returned.
+It used to croak on values returned by C<shift> and C<delete> and from
+other subroutines, but no longer does so [perl #71172].
-=back
+=item *
-One side effect of these changes is that blessing into "\0" no longer
-causes C<ref()> to return false.
+Empty lvalue subroutines (C<sub :lvalue {}>) used to return C<@_> in list
+context. In fact, all subroutines used to, but regular subs were fixed in
+Perl 5.8.2. Now lvalue subroutines have been likewise fixed.
-=head2 Filetests and C<stat>
+=item *
-The term "filetests" refers to the operators that consist of a hyphen
-followed by a single letter: C<-r>, C<-x>, C<-M>, etc. The term "stacked"
-when applied to filetests means followed by another filetest operator
-sharing the same operand, as in C<-r -x -w $fooo>.
+Autovivification now works on values returned from lvalue subroutines
+[perl #7946], as does returning C<keys> in lvalue context.
-=over
+=item *
+
+Lvalue subroutines used to copy their return values in rvalue context. Not
+only was this a waste of CPU cycles, but it also caused bugs. A C<($)>
+prototype would cause an lvalue sub to copy its return value [perl #51408],
+and C<while(lvalue_sub() =~ m/.../g) { ... }> would loop endlessly
+[perl #78680].
=item *
-C<stat> produces more consistent warnings. It no longer warns for "_"
-[perl #71002] and no longer skips the warning at times for other unopened
-handles. It no longer warns about an unopened handle when the operating
-system's C<fstat> function fails.
+When called in potential lvalue context
+(e.g., subroutine arguments or a list
+passed to C<for>), lvalue subroutines used to copy
+any read-only value that was returned. E.g., C< sub :lvalue { $] } >
+would not return C<$]>, but a copy of it.
=item *
-C<stat> would sometimes return negative numbers for large inode numbers,
-because it was using the wrong internal C type. [perl #84590]
+When called in potential lvalue context, an lvalue subroutine returning
+arrays or hashes used to bind the arrays or hashes to scalar variables,
+resulting in bugs. This was fixed in 5.14.0 if an array were the first
+thing returned from the subroutine (but not for C<$scalar, @array> or
+hashes being returned). Now a more general fix has been applied
+[perl #23790].
=item *
-C<lstat> is documented to fall back to C<stat> (with a warning) when given
-a filehandle. When passed an IO reference, it was actually doing the
-equivalent of S<C<stat _>> and ignoring the handle.
+Method calls whose arguments were all surrounded with C<my()> or C<our()>
+(as in C<< $object->method(my($a,$b)) >>) used to force lvalue context on
+the subroutine. This would prevent lvalue methods from returning certain
+values.
=item *
-C<-T _> with no preceding C<stat> used to produce a
-confusing "uninitialized" warning, even though there
-is no visible uninitialized value to speak of.
+Lvalue sub calls that are not determined to be such at compile time
+(C<&$name> or &{"name"}) are no longer exempt from strict refs if they
+occur in the last statement of an lvalue subroutine [perl #102486].
=item *
-C<-T>, C<-B>, C<-l> and C<-t> now work
-when stacked with other filetest operators
-[perl #77388].
+Sub calls whose subs are not visible at compile time, if
+they occurred in the last statement of an lvalue subroutine,
+would reject non-lvalue subroutines and die with "Can't modify non-lvalue
+subroutine call" [perl #102486].
+
+Non-lvalue sub calls whose subs I<are> visible at compile time exhibited
+the opposite bug. If the call occurred in the last statement of an lvalue
+subroutine, there would be no error when the lvalue sub was called in
+lvalue context. Perl would blindly assign to the temporary value returned
+by the non-lvalue subroutine.
=item *
-In 5.14.0, filetest ops (C<-r>, C<-x>, etc.) started calling FETCH on a
-tied argument belonging to the previous argument to a list operator, if
-called with a bareword argument or no argument at all. This has been
-fixed, so C<push @foo, $tied, -r> no longer calls FETCH on C<$tied>.
+C<AUTOLOAD> routines used to take precedence over the actual sub being
+called (i.e., when autoloading wasn't needed), for sub calls in lvalue or
+potential lvalue context, if the subroutine was not visible at compile
+time.
=item *
-In Perl 5.6, C<-l> followed by anything other than a bareword would treat
-its argument as a file name. That was changed in 5.8 for glob references
-(C<\*foo>), but not for globs themselves (C<*foo>). C<-l> started
-returning C<undef> for glob references without setting the last
-stat buffer that the "_" handle uses, but only if warnings
-were turned on. With warnings off, it was the same as 5.6.
-In other words, it was simply buggy and inconsistent. Now the 5.6
-behaviour has been restored.
+Applying the C<:lvalue> attribute to an XSUB or to an aliased subroutine
+stub with C<< sub foo :lvalue; >> syntax stopped working in Perl 5.12.
+This has been fixed.
=item *
-C<-l> followed by a bareword no longer "eats" the previous argument to
-the list operator in whose argument list it resides. Hence,
-C<print "bar", -l foo> now actually prints "bar", because C<-l>
-on longer eats it.
+Applying the :lvalue attribute to subroutine that is already defined does
+not work properly, as the attribute changes the way the sub is compiled.
+Hence, Perl 5.12 began warning when an attempt is made to apply the
+attribute to an already defined sub. In such cases, the attribute is
+discarded.
+
+But the change in 5.12 missed the case where custom attributes are also
+present: that case still silently and ineffectively applied the attribute.
+That omission has now been corrected. C<sub foo :lvalue :Whatever> (when
+C<foo> is already defined) now warns about the :lvalue attribute, and does
+not apply it.
=item *
-Perl keeps several internal variables to keep track of the last stat
-buffer, from which file(handle) it originated, what type it was, and
-whether the last stat succeeded.
+A bug affecting lvalue context propagation through nested lvalue subroutine
+calls has been fixed. Previously, returning a value in nested rvalue
+context would be treated as lvalue context by the inner subroutine call,
+resulting in some values (such as read-only values) being rejected.
+
+=back
+
+=head2 Overloading
+
+=over
+
+=item *
+
+Arithmetic assignment (C<$left += $right>) involving overloaded objects
+that rely on the 'nomethod' override no longer segfault when the left
+operand is not overloaded.
+
+=item *
+
+Errors that occur when methods cannot be found during overloading now
+mention the correct package name, as they did in 5.8.x, instead of
+erroneously mentioning the "overload" package, as they have since 5.10.0.
+
+=item *
+
+Undefining C<%overload::> no longer causes a crash.
+
+=back
+
+=head2 Prototypes of built-in keywords
+
+=over
+
+=item *
+
+The C<prototype> function no longer dies for the C<__FILE__>, C<__LINE__>
+and C<__PACKAGE__> directives. It now returns an empty-string prototype
+for them, because they are syntactically indistinguishable from nullary
+functions like C<time>.
+
+=item *
+
+C<prototype> now returns C<undef> for all overridable infix operators,
+such as C<eq>, which are not callable in any way resembling functions.
+It used to return incorrect prototypes for some and die for others
+[perl #94984].
+
+=item *
+
+The prototypes of several built-in functions--C<getprotobynumber>, C<lock>,
+C<not> and C<select>--have been corrected, or at least are now closer to
+reality than before.
+
+=back
+
+=head2 Regular expressions
+
+=for comment Is it possible to merge some of these items?
+
+=over 4
+
+=item *
+
+C</[[:ascii:]]/> and C</[[:blank:]]/> now use locale rules under
+C<use locale> when the platform supports that. Previously, they used
+the platform's native character set.
+
+=item *
+
+C<m/[[:ascii:]]/i> and C</\p{ASCII}/i> now match identically (when not
+under a differing locale). This fixes a regression introduced in 5.14
+in which the first expression could match characters outside of ASCII,
+such as the KELVIN SIGN.
+
+=item *
+
+C</.*/g> would sometimes refuse to match at the end of a string that ends
+with "\n". This has been fixed [perl #109206].
+
+=item *
+
+Starting with 5.12.0, Perl used to get its internal bookkeeping muddled up
+after assigning C<${ qr// }> to a hash element and locking it with
+L<Hash::Util>. This could result in double frees, crashes or erratic
+behaviour.
+
+=item *
+
+The new (in 5.14.0) regular expression modifier C</a> when repeated like
+C</aa> forbids the characters outside the ASCII range that match
+characters inside that range from matching under C</i>. This did not
+work under some circumstances, all involving alternation, such as:
+
+ "\N{KELVIN SIGN}" =~ /k|foo/iaa;
+
+succeeded inappropriately. This is now fixed.
+
+=item *
+
+5.14.0 introduced some memory leaks in regular expression character
+classes such as C<[\w\s]>, which have now been fixed. (5.14.1)
+
+=item *
+
+An edge case in regular expression matching could potentially loop.
+This happened only under C</i> in bracketed character classes that have
+characters with multi-character folds, and the target string to match
+against includes the first portion of the fold, followed by another
+character that has a multi-character fold that begins with the remaining
+portion of the fold, plus some more.
+
+ "s\N{U+DF}" =~ /[\x{DF}foo]/i
+
+is one such case. C<\xDF> folds to C<"ss">. (5.14.1)
+
+=item *
+
+A few characters in regular expression pattern matches did not
+match correctly in some circumstances, all involving C</i>. The
+affected characters are:
+COMBINING GREEK YPOGEGRAMMENI,
+GREEK CAPITAL LETTER IOTA,
+GREEK CAPITAL LETTER UPSILON,
+GREEK PROSGEGRAMMENI,
+GREEK SMALL LETTER IOTA WITH DIALYTIKA AND OXIA,
+GREEK SMALL LETTER IOTA WITH DIALYTIKA AND TONOS,
+GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND OXIA,
+GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND TONOS,
+LATIN SMALL LETTER LONG S,
+LATIN SMALL LIGATURE LONG S T,
+and
+LATIN SMALL LIGATURE ST.
+
+=item *
+
+A memory leak regression in regular expression compilation
+under threading has been fixed.
+
+=item *
+
+A regression introduced in 5.13.6 has
+been fixed. This involved an inverted
+bracketed character class in a regular expression that consisted solely
+of a Unicode property. That property wasn't getting inverted outside the
+Latin1 range.
+
+=item *
+
+Three problematic Unicode characters now work better in regex pattern matching under C</i>
+
+In the past, three Unicode characters:
+LATIN SMALL LETTER SHARP S,
+GREEK SMALL LETTER IOTA WITH DIALYTIKA AND TONOS,
+and
+GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND TONOS,
+along with the sequences that they fold to
+(including "ss" in the case of LATIN SMALL LETTER SHARP S),
+did not properly match under C</i>. 5.14.0 fixed some of these cases,
+but introduced others, including a panic when one of the characters or
+sequences was used in the C<(?(DEFINE)> regular expression predicate.
+The known bugs that were introduced in 5.14 have now been fixed; as well
+as some other edge cases that have never worked until now. All these
+involve using the characters and sequences outside bracketed character
+classes under C</i>. This closes [perl #98546].
+
+There remain known problems when using certain characters with
+multi-character folds inside bracketed character classes, including such
+constructs as C<qr/[\N{LATIN SMALL LETTER SHARP}a-z]/i>. These
+remaining bugs are addressed in [perl #89774].
+
+=item *
+
+RT #78266: The regex engine has been leaking memory when accessing
+named captures that weren't matched as part of a regex ever since 5.10
+when they were introduced, e.g. this would consume over a hundred MB of
+memory:
+
+ for (1..10_000_000) {
+ if ("foo" =~ /(foo|(?<capture>bar))?/) {
+ my $capture = $+{capture}
+ }
+ }
+ system "ps -o rss $$"'
+
+=item *
+
+In 5.14, C</[[:lower:]]/i> and C</[[:upper:]]/i> no longer matched the
+opposite case. This has been fixed [perl #101970].
+
+=item *
+
+A regular expression match with an overloaded object on the right-hand side
+would in some cases stringify the object too many times.
+
+=item *
+
+A regression has been fixed that was introduced in 5.14, in C</i>
+regular expression matching, in which a match improperly fails if the
+pattern is in UTF-8, the target string is not, and a Latin-1 character
+precedes a character in the string that should match the pattern.
+[perl #101710]
+
+=item *
+
+In case-insensitive regular expression pattern matching, no longer on
+UTF-8 encoded strings does the scan for the start of match only look at
+the first possible position. This caused matches such as
+C<"f\x{FB00}" =~ /ff/i> to fail.
+
+=item *
+
+The regexp optimiser no longer crashes on debugging builds when merging
+fixed-string nodes with inconvenient contents.
+
+=item *
+
+A panic involving the combination of the regular expression modifiers
+C</aa> and the C<\b> escape sequence introduced in 5.14.0 has been
+fixed [perl #95964].
+
+=item *
+
+The combination of the regular expression modifiers C</aa> and the C<\b>
+and C<\B> escape sequences did not work properly on UTF-8 encoded
+strings. All non-ASCII characters under C</aa> should be treated as
+non-word characters, but what was happening was that Unicode rules were
+used to determine wordness/non-wordness for non-ASCII characters. This
+is now fixed [perl #95968].
+
+=item *
+
+C<< (?foo: ...) >> no longer loses passed in character set.
+
+=item *
+
+The trie optimisation used to have problems with alternations containing
+an empty C<(?:)>, causing C<< "x" =~ /\A(?>(?:(?:)A|B|C?x))\z/ >> not to
+match, whereas it should [perl #111842].
+
+=item *
+
+Use of lexical (C<my>) variables in code blocks embedded in regular
+expressions will no longer result in memory corruption or crashes.
+
+Nevertheless, these code blocks are still experimental, as there are still
+problems with the wrong variables being closed over (in loops for instance)
+and with abnormal exiting (e.g., C<die>) causing memory corruption.
+
+=item *
+
+The C<\h>, C<\H>, C<\v> and C<\V> regular expression metacharacters used to
+cause a panic error message when attempting to match at the end of the
+string [perl #96354].
+
+=item *
+
+The abbreviations for four C1 control characters C<MW> C<PM>, C<RI>, and
+C<ST> were previously unrecognized by C<\N{}>, vianame(), and
+string_vianame().
+
+=item *
+
+Mentioning a variable named "&" other than C<$&> (i.e., C<@&> or C<%&>) no
+longer stops C<$&> from working. The same applies to variables named "'"
+and "`" [perl #24237].
+
+=item *
+
+Creating a C<UNIVERSAL::AUTOLOAD> sub no longer stops C<%+>, C<%-> and
+C<%!> from working some of the time [perl #105024].
+
+=back
+
+=head2 Smartmatching
+
+=over
+
+=item *
+
+C<~~> now correctly handles the precedence of Any~~Object, and is not tricked
+by an overloaded object on the left-hand side.
+
+=item *
+
+In Perl 5.14.0, C<$tainted ~~ @array> stopped working properly. Sometimes
+it would erroneously fail (when C<$tainted> contained a string that occurs
+in the array I<after> the first element) or erroneously succeed (when
+C<undef> occurred after the first element) [perl #93590].
+
+=back
+
+=head2 The C<sort> operator
+
+=over
+
+=item *
+
+C<sort> was not treating C<sub {}> and C<sub {()}> as equivalent when
+such a sub was provided as the comparison routine. It used to croak on
+C<sub {()}>.
+
+=item *
+
+C<sort> now works once more with custom sort routines that are XSUBs. It
+stopped working in 5.10.0.
+
+=item *
+
+C<sort> with a constant for a custom sort routine, although it produces
+unsorted results, no longer crashes. It started crashing in 5.10.0.
+
+=item *
+
+Warnings emitted by C<sort> when a custom comparison routine returns a
+non-numeric value now contain "in sort" and show the line number of the
+C<sort> operator, rather than the last line of the comparison routine. The
+warnings also occur now only if warnings are enabled in the scope where
+C<sort> occurs. Previously the warnings would occur if enabled in the
+comparison routine's scope.
+
+=item *
+
+C<< sort { $a <=> $b } >>, which is optimised internally, now produces
+"uninitialized" warnings for NaNs (not-a-number values), since C<< <=> >>
+returns C<undef> for those. This brings it in line with
+S<C<< sort { 1; $a <=> $b } >>> and other more complex cases, which are not
+optimised [perl #94390].
+
+=back
+
+=head2 The C<substr> operator
+
+=over
+
+=item *
+
+Tied (and otherwise magical) variables are no longer exempt from the
+"Attempt to use reference as lvalue in substr" warning.
+
+=item *
+
+That warning now occurs when the returned lvalue is assigned to, not
+when C<substr> itself is called. This only makes a difference if the
+return value of C<substr> is referenced and assigned to later.
+
+=item *
+
+Passing a substring of a read-only value or a typeglob to a function
+(potential lvalue context) no longer causes an immediate "Can't coerce"
+or "Modification of a read-only value" error. That error only occurs
+if and when the value passed is assigned to.
+
+The same thing happens with the "substr outside of string" error. If
+the lvalue is only read, not written to, it is now just a warning, as
+with rvalue C<substr>.
+
+=item *
+
+C<substr> assignments no longer call FETCH twice if the first argument
+is a tied variable, just once.
+
+=back
-There were various cases where these could get out of synch, resulting in
-inconsistent or erratic behaviour in edge cases (every mention of C<-T>
-applies to C<-B> as well):
+=head2 Support for embedded nulls
+
+Some parts of Perl did not work correctly with nulls (C<chr 0>) embedded in
+strings. That meant that, for instance, C<< $m = "a\0b"; foo->$m >> would
+call the "a" method, instead of the actual method name contained in $m.
+These parts of perl have been fixed to support nulls:
=over
=item *
-C<-T I<HANDLE>>, even though it does a C<stat>, was not resetting the last
-stat type, so an C<lstat _> following it would merrily return the wrong
-results. Also, it was not setting the success status.
+Method names
=item *
-Freeing the handle last used by C<stat> or a filetest could result in
-S<C<-T _>> using an unrelated handle.
+Typeglob names (including filehandle and subroutine names)
=item *
-C<stat> with an IO reference would not reset the stat type or record the
-filehandle for S<C<-T _>> to use.
+Package names, including the return value of C<ref()>
=item *
-Fatal warnings could cause the stat buffer not to be reset
-for a filetest operator on an unopened filehandle or C<-l> on any handle.
-Fatal warnings also stopped C<-T> from setting C<$!>.
+Typeglob elements (C<*foo{"THING\0stuff"}>)
=item *
-When the last stat was on an unreadable file, C<-T _> is supposed to
-return C<undef>, leaving the last stat buffer unchanged. But it was
-setting the stat type, causing C<lstat _> to stop working.
+Signal names
=item *
-C<-T I<FILENAME>> was not resetting the internal stat buffers for
-unreadable files.
+Various warnings and error messages that mention variable names or values,
+methods, etc.
=back
-These have all been fixed.
-
-=back
+One side effect of these changes is that blessing into "\0" no longer
+causes C<ref()> to return false.
-=head2 Version objects and vstrings
+=head2 Threading bugs
=over
=item *
-The bitwise complement operator (and possibly other operators, too) when
-passed a vstring would leave vstring magic attached to the return value,
-even though the string had changed. This meant that
-C<< version->new(~v1.2.3) >> would create a version looking like "v1.2.3"
-even though the string passed to C<< version->new >> was actually
-"\376\375\374". This also caused L<B::Deparse> to deparse C<~v1.2.3>
-incorrectly, without the C<~> [perl #29070].
+Typeglobs returned from threads are no longer cloned if the parent thread
+already has a glob with the same name. This means that returned
+subroutines will now assign to the right package variables [perl #107366].
=item *
-Assigning a vstring to a magic (e.g., tied, C<$!>) variable and then
-assigning something else used to blow away all the magic. This meant that
-tied variables would come undone, C<$!> would stop getting updated on
-failed system calls, C<$|> would stop setting autoflush, and other
-mischief would take place. This has been fixed.
+Some cases of threads crashing due to memory allocation during cloning have
+been fixed [perl #90006].
=item *
-C<< version->new("version") >> and C<printf "%vd", "version"> no longer
-crash [perl #102586].
+Thread joining would sometimes emit "Attempt to free unreferenced scalar"
+warnings if C<caller> had been used from the C<DB> package prior to thread
+creation [perl #98092].
=item *
-Version comparisons, such as those that happen implicitly with C<use
-v5.43>, no longer cause locale settings to change [perl #105784].
-
-=item *
+Locking a subroutine (via C<lock &sub>) is no longer a compile-time error
+for regular subs. For lvalue subroutines, it no longer tries to return the
+sub as a scalar, resulting in strange side effects like C<ref \$_>
+returning "CODE" in some instances.
-Version objects no longer cause memory leaks in boolean context
-[perl #109762].
+C<lock &sub> is now a run-time error if L<threads::shared> is loaded (a
+no-op otherwise), but that may be rectified in a future version.
=back
=item *
+When calling C<local $_> [perl #105912]
+
+=item *
+
Four-argument C<select>
=item *
=back
-=head2 "Uninitialized" warnings
+=head2 Version objects and vstrings
=over
=item *
-Various functions that take a filehandle argument in rvalue context
-(C<close>, C<readline>, etc.) used to warn twice for an undefined handle
-[perl #97482].
-
-=item *
-
-C<dbmopen> now only warns once, rather than three times, if the mode
-argument is C<undef> [perl #90064].
-
-=item *
-
-The C<+=> operator does not usually warn when the left-hand side is
-C<undef>, but it was doing so for tied variables. This has been fixed
-[perl #44895].
+The bitwise complement operator (and possibly other operators, too) when
+passed a vstring would leave vstring magic attached to the return value,
+even though the string had changed. This meant that
+C<< version->new(~v1.2.3) >> would create a version looking like "v1.2.3"
+even though the string passed to C<< version->new >> was actually
+"\376\375\374". This also caused L<B::Deparse> to deparse C<~v1.2.3>
+incorrectly, without the C<~> [perl #29070].
=item *
-A bug fix in Perl 5.14 introduced a new bug, causing "uninitialized"
-warnings to report the wrong variable if the operator in question had
-two operands and one was C<%{...}> or C<@{...}>. This has been fixed
-[perl #103766].
+Assigning a vstring to a magic (e.g., tied, C<$!>) variable and then
+assigning something else used to blow away all the magic. This meant that
+tied variables would come undone, C<$!> would stop getting updated on
+failed system calls, C<$|> would stop setting autoflush, and other
+mischief would take place. This has been fixed.
=item *
-C<..> and C<...> in list context now mention the name of the variable in
-"uninitialized" warnings for string (as opposed to numeric) ranges.
-
-=back
-
-=head2 Last-accessed filehandle
-
-Perl has an internal variable that stores the last filehandle to be
-accessed. It is used by C<$.> and by C<tell> and C<eof> without
-arguments.
-
-=over
+C<< version->new("version") >> and C<printf "%vd", "version"> no longer
+crash [perl #102586].
=item *
-It used to be possible to set this internal variable to a glob copy and
-then modify that glob copy to be something other than a glob, and still
-have the last-accessed filehandle associated with the variable after
-assigning a glob to it again:
-
- my $foo = *STDOUT; # $foo is a glob copy
- <$foo>; # $foo is now the last-accessed handle
- $foo = 3; # no longer a glob
- $foo = *STDERR; # still the last-accessed handle
-
-Now the C<$foo = 3> assignment unsets that internal variable, so there
-is no last-accessed filehandle, just as if C<< <$foo> >> had never
-happened.
-
-This also prevents some unrelated handle from becoming the last-accessed
-handle if $foo falls out of scope and the same internal SV gets used for
-another handle [perl #97988].
+Version comparisons, such as those that happen implicitly with C<use
+v5.43>, no longer cause locale settings to change [perl #105784].
=item *
-A regression in 5.14 caused these statements not to set that internal
-variable:
-
- my $fh = *STDOUT;
- tell $fh;
- eof $fh;
- seek $fh, 0,0;
- tell *$fh;
- eof *$fh;
- seek *$fh, 0,0;
- readline *$fh;
-
-This is now fixed, but C<tell *{ *$fh }> still has the problem, and it
-is not clear how to fix it [perl #106536].
+Version objects no longer cause memory leaks in boolean context
+[perl #109762].
=back
-=head2 Redefinition warnings
+=head2 Warnings, redefinition
=over
subroutine:
use warnings;
- BEGIN {
- no warnings;
- some_XS_function_that_calls_new_CONSTSUB();
- }
-
-=item *
-
-Redefinition warnings for constant subroutines are on by default (what
-are known as severe warnings in L<perldiag>). This was only the case
-when it was a glob assignment or declaration of a Perl subroutine that
-caused the warning. If the creation of XSUBs triggered the warning, it
-was not a default warning. This has been corrected.
-
-=item *
-
-The internal check to see whether a redefinition warning should occur
-used to emit "uninitialized" warnings in cases like this:
-
- use warnings "uninitialized";
- use constant {u => undef, v => undef};
- sub foo(){u}
- sub foo(){v}
-
-=back
-
-=head2 Overloading
-
-=over
-
-=item *
-
-Arithmetic assignment (C<$left += $right>) involving overloaded objects
-that rely on the 'nomethod' override no longer segfault when the left
-operand is not overloaded.
-
-=item *
-
-Errors that occur when methods cannot be found during overloading now
-mention the correct package name, as they did in 5.8.x, instead of
-erroneously mentioning the "overload" package, as they have since 5.10.0.
-
-=item *
-
-Undefining C<%overload::> no longer causes a crash.
-
-=back
-
-=head2 Fixes to the C<sort> operator
-
-=over
-
-=item *
-
-C<sort> was not treating C<sub {}> and C<sub {()}> as equivalent when
-such a sub was provided as the comparison routine. It used to croak on
-C<sub {()}>.
-
-=item *
-
-C<sort> now works once more with custom sort routines that are XSUBs. It
-stopped working in 5.10.0.
-
-=item *
-
-C<sort> with a constant for a custom sort routine, although it produces
-unsorted results, no longer crashes. It started crashing in 5.10.0.
-
-=item *
-
-Warnings emitted by C<sort> when a custom comparison routine returns a
-non-numeric value now contain "in sort" and show the line number of the
-C<sort> operator, rather than the last line of the comparison routine. The
-warnings also occur now only if warnings are enabled in the scope where
-C<sort> occurs. Previously the warnings would occur if enabled in the
-comparison routine's scope.
-
-=item *
-
-C<< sort { $a <=> $b } >>, which is optimised internally, now produces
-"uninitialized" warnings for NaNs (not-a-number values), since C<< <=> >>
-returns C<undef> for those. This brings it in line with
-S<C<< sort { 1; $a <=> $b } >>> and other more complex cases, which are not
-optimised [perl #94390].
-
-=back
-
-=head2 Fixes affecting the debugger
-
-=over
-
-=item *
-
-F<dumpvar.pl>, and consequently the C<x> command in the debugger, have been
-fixed to handle objects blessed into classes whose names contain "=". The
-contents of such objects used not to be dumped [perl #101814].
-
-=item *
-
-The "R" command for restarting a debugger session has been fixed to work on
-Windows, or any other system lacking a C<POSIX::_SC_OPEN_MAX> constant
-[perl #87740].
-
-=item *
-
-The C<#line 42 foo> directive used not to update the arrays of lines used
-by the debugger if it occurred in a string eval. This was partially fixed
-in 5.14, but it only worked for a single C<#line 42 foo> in each eval. Now
-it works for multiple.
+ BEGIN {
+ no warnings;
+ some_XS_function_that_calls_new_CONSTSUB();
+ }
=item *
-When subroutine calls are intercepted by the debugger, the name of the
-subroutine or a reference to it is stored in C<$DB::sub>, for the debugger
-to access. In some cases (such as C<$foo = *bar; undef *bar; &$foo>)
-C<$DB::sub> would be set to a name that could not be used to find the
-subroutine, and so the debugger's attempt to call it would fail. Now the
-check to see whether a reference is needed is more robust, so those
-problems should not happen anymore [rt.cpan.org #69862].
+Redefinition warnings for constant subroutines are on by default (what
+are known as severe warnings in L<perldiag>). This was only the case
+when it was a glob assignment or declaration of a Perl subroutine that
+caused the warning. If the creation of XSUBs triggered the warning, it
+was not a default warning. This has been corrected.
=item *
-Every subroutine has a filename associated with it that the debugger uses.
-The one associated with constant subroutines used to be misallocated when
-cloned under threads. Consequently, debugging threaded applications could
-result in memory corruption [perl #96126].
+The internal check to see whether a redefinition warning should occur
+used to emit "uninitialized" warnings in cases like this:
+
+ use warnings "uninitialized";
+ use constant {u => undef, v => undef};
+ sub foo(){u}
+ sub foo(){v}
=back
-=head2 Fixes to the C<glob> operator
+=head2 Warnings, "Uninitialized"
=over
=item *
-On OSes other than VMS, Perl's C<glob> operator (and the C<< <...> >> form)
-use L<File::Glob> underneath. L<File::Glob> splits the pattern into words,
-before feeding each word to its C<bsd_glob> function.
-
-There were several inconsistencies in the way the split was done. Now
-quotation marks (' and ") are always treated as shell-style word delimiters
-(that allow whitespace as part of a word) and backslashes are always
-preserved, unless they exist to escape quotation marks. Before, those
-would only sometimes be the case, depending on whether the pattern
-contained whitespace. Also, escaped whitespace at the end of the pattern
-is no longer stripped [perl #40470].
+Various functions that take a filehandle argument in rvalue context
+(C<close>, C<readline>, etc.) used to warn twice for an undefined handle
+[perl #97482].
=item *
-C<CORE::glob> now works as a way to call the default globbing function. It
-used to respect overrides, despite the C<CORE::> prefix.
+C<dbmopen> now only warns once, rather than three times, if the mode
+argument is C<undef> [perl #90064].
=item *
-Under miniperl (used to configure modules when perl itself is built),
-C<glob> now clears %ENV before calling csh, since the latter croaks on some
-systems if it does not like the contents of the LS_COLORS enviroment
-variable [perl #98662].
-
-=back
+The C<+=> operator does not usually warn when the left-hand side is
+C<undef>, but it was doing so for tied variables. This has been fixed
+[perl #44895].
-=head2 Fixes affecting the C API
+=item *
-=over
+A bug fix in Perl 5.14 introduced a new bug, causing "uninitialized"
+warnings to report the wrong variable if the operator in question had
+two operands and one was C<%{...}> or C<@{...}>. This has been fixed
+[perl #103766].
=item *
-The C<newHVhv> XS function now works on tied hashes, instead of crashing or
-returning an empty hash.
+C<..> and C<...> in list context now mention the name of the variable in
+"uninitialized" warnings for string (as opposed to numeric) ranges.
-=item *
+=back
-The C<SvIsCOW> C macro now returns false for read-only copies of typeglobs,
-such as those created by:
+=head2 Weak references
- $hash{elem} = *foo;
- Hash::Util::lock_value %hash, 'elem';
+=over
-It used to return true.
+=item *
+
+Weakening the first argument to an automatically-invoked C<DESTROY> method
+could result in erroneous "DESTROY created new reference" errors or
+crashes. Now it is an error to weaken a read-only reference.
=item *
-The C<SvPVutf8> C function no longer tries to modify its argument,
-resulting in errors [perl #108994].
+Weak references to lexical hashes going out of scope were not going stale
+(becoming undefined), but continued to point to the hash.
=item *
-C<SvPVutf8> now works properly with magical variables.
+Weak references to lexical variables going out of scope are now broken
+before any magical methods (e.g., DESTROY on a tie object) are called.
+This prevents such methods from modifying the variable that will be seen
+the next time the scope is entered.
=item *
-C<SvPVbyte> now works properly non-PVs.
+Creating a weak reference to an @ISA array or accessing the array index
+(C<$#ISA>) could result in confused internal bookkeeping for elements
+subsequently added to the @ISA array. For instance, creating a weak
+reference to the element itself could push that weak reference on to @ISA;
+and elements added after use of C<$#ISA> would be ignored by method lookup
+[perl #85670].
=back
=item *
-C<~~> now correctly handles the precedence of Any~~Object, and is not tricked
-by an overloaded object on the left-hand side.
-
-=item *
-
C<quotemeta> now quotes consistently the same non-ASCII characters under
C<use feature 'unicode_strings'>, regardless of whether the string is
encoded in UTF-8 or not, hence fixing the last vestiges (we hope) of the
=item *
-No warning for C<open(foo::bar)>
-
When one writes C<open foo || die>, which used to work in Perl 4, a
"Precedence problem" warning is produced. This warning used erroneously to
apply to fully-qualified bareword handle names not followed by C<||>. This
=item *
-C<select> and package aliasing
-
After package aliasing (C<*foo:: = *bar::>), C<select> with 0 or 1 argument
would sometimes return a name that could not be used to refer to the
filehandle, or sometimes it would return C<undef> even when a filehandle
=item *
-C<PerlIO::get_layers> and numbers
-
C<PerlIO::get_layers> no longer ignores some arguments that it thinks are
numeric, while treating others as filehandle names. It is now consistent
for flat scalars (i.e., not references).
=item *
-C<system> and SIGCHLD
-
C<system> now temporarily blocks the SIGCHLD signal handler, to prevent the
signal handler from stealing the exit status [perl #105700].
=item *
-C<(s)printf>'s %n formatting code
-
-The %n formatting code, which causes the number of characters to be
-assigned to the next argument to C<printf> or C<sprintf> now actually
+The %n formatting code for C<printf> and C<sprintf>, which causes the number
+of characters to be assigned to the next argument, now actually
assigns the number of characters, instead of the number of bytes.
It also works now with special lvalue functions like C<substr> and with
=item *
-Typeglobs and threads
-
-Typeglobs returned from threads are no longer cloned if the parent thread
-already has a glob with the same name. This means that returned
-subroutines will now assign to the right package variables [perl #107366].
-
-=item *
-
-C<local $_>
-
-In Perl 5.14, C<local $_> was changed to create a new variable not tied to
-anything, even if $_ was tied before that. But, due to an oversight, it
-would still call FETCH once on a tied $_ before replacing it with the new
-variable. This has been fixed [perl #105912].
-
-=item *
-
-Returning tied variables
-
-When returning a value from a non-lvalue subroutine, Perl copies the value.
-Sometimes it cheats for the sake of speed, and does not copy the value if
-it makes no observable difference. This optimisation was erroneously
-allowing the copy to be skipped on tied variables, causing a difference in
-behaviour depending on the tied variable's reference count. This has been
-fixed [perl #95548].
+Perl skips copying values returned from a subroutine, for the sake of
+speed, if doing so would make no observable difference. Due to faulty
+logic, this would happen with the
+result of C<delete>, C<shift> or C<splice>, even if the result was
+referenced elsewhere. It also did so with tied variables about to be freed
+[perl #91844, #95548].
=item *
=item *
-Freeing $_ inside C<grep> or C<map>
-
-Freeing $_ inside a C<grep> or C<map> block or a code block embedded in a
-regular expression used to result in double frees [perl #92254, #92256].
-
-=item *
-
-C<@&> and C<$&>
-
-Mentioning a variable named "&" other than C<$&> (i.e., C<@&> or C<%&>) no
-longer stops C<$&> from working. The same applies to variables named "'"
-and "`" [perl #24237].
+Freeing $_ inside a C<grep> or C<map> block, a code block embedded in a
+regular expression, or an @INC filter (a subroutine returned by a
+subroutine in @INC) used to result in double frees or crashes
+[perl #91880, #92254, #92256].
=item *
-Return value of C<eval>
-
C<eval> returns C<undef> in scalar context or an empty list in list
context when there is a run-time error. When C<eval> was passed a
string in list context and a syntax error occurred, it used to return a
=item *
-Creating a C<UNIVERSAL::AUTOLOAD> sub no longer stops C<%+>, C<%-> and
-C<%!> from working some of the time [perl #105024].
-
-=item *
-
-When presented with malformed UTF-8 input, the XS-callable functions
-C<is_utf8_string()>, C<is_utf8_string_loc()>, and
-C<is_utf8_string_loclen()> could read beyond the end of the input
-string by up to 12 bytes. This no longer happens. [perl #32080].
-However, currently, C<is_utf8_char()> still has this defect, see
-L</is_utf8_char()> above.
-
-=item *
-
Perl now holds an extra reference count on the package that code is
-currently compiling in. This means that the following code no longer crashes [perl #101486]:
+currently compiling in. This means that the following code no longer
+crashes [perl #101486]:
package Foo;
BEGIN {*Foo:: = *Bar::}
=item *
-The C-level C<pregcomp> function could become confused as to whether the
-pattern was in UTF8 if the pattern was an overloaded, tied, or otherwise
-magical scalar [perl #101940].
-
-=item *
-
Calling C<require> on an implicit C<$_> when C<*CORE::GLOBAL::require> has
been overridden does not segfault anymore, and C<$_> is now passed to the
overriding subroutine [perl #78260].
=item *
-In Perl 5.14.0, C<$tainted ~~ @array> stopped working properly. Sometimes
-it would erroneously fail (when C<$tainted> contained a string that occurs
-in the array I<after> the first element) or erroneously succeed (when
-C<undef> occurred after the first element) [perl #93590].
-
-=item *
-
C<use> and C<require> are no longer affected by the I/O layers active in
the caller's scope (enabled by L<open.pm|open>) [perl #96008].
any objects that might be left after the usual passes that check for
objects referenced by scalars [perl #36347].
-This bug fix was added in Perl 5.13.9, but caused problems with some CPAN
-modules that were relying on the bug. Since it was so close to Perl
-5.14.0, the fix was reverted in 5.13.10, to allow more time for the modules
-to adapt. Hopefully they will be fixed soon (see L</Known Problems>,
-below).
-
-=item *
-
-C<given> was not calling set-magic on the implicit lexical C<$_> that it
-uses. This meant, for example, that C<pos> would be remembered from one
-execution of the same C<given> block to the next, even if the input were a
-different variable [perl #84526].
-
=item *
Fixed a case where it was possible that a freed buffer may have been read
=item *
-In @INC filters (subroutines returned by subroutines in @INC), $_ used to
-misbehave: If returned from a subroutine, it would not be copied, but the
-variable itself would be returned; and freeing $_ (e.g., with C<undef *_>)
-would cause perl to crash. This has been fixed [perl #91880].
-
-=item *
-
-An ASCII single quote (') in a symbol name is meant to be equivalent to a
-double colon (::) except at the end of the name. It was not equivalent if
-followed by a null character, but now it is [perl #88138].
-
-=item *
-
-The abbreviations for four C1 control characters C<MW> C<PM>, C<RI>, and
-C<ST> were previously unrecognized by C<\N{}>, vianame(), and
-string_vianame().
-
-=item *
-
-Some cases of threads crashing due to memory allocation during cloning have
-been fixed [perl #90006].
-
-=item *
-
-Perl skips copying values returned from a subroutine if it thinks the value
-is not in use elsewhere. Due to faulty logic, this would happen with the
-result of C<delete>, C<shift> or C<splice>, even if the result was
-referenced elsewhere. So C<< \sub { delete $_[0] }->($x) >> would return a
-reference to C<$x>. This has been fixed [perl #91844].
-
-=item *
-
-The C<prototype> function no longer dies for the C<__FILE__>, C<__LINE__>
-and C<__PACKAGE__> directives. It now returns an empty-string prototype
-for them, because they are syntactically very similar to nullary functions
-like C<time>.
-
-=item *
-
-C<prototype> now returns C<undef> for all overridable infix operators,
-such as C<eq>, which are not callable in any way resembling functions.
-It used to return incorrect prototypes for some and die for others
-[perl #94984].
-
-=item *
-
-C<when> blocks are now capable of returning variables declared inside the
-enclosing C<given> block [perl #93548].
-
-=item *
-
A problem with context propagation when a C<do> block is an argument to
C<return> has been fixed. It used to cause C<undef> to be returned in
some cases of a C<return> inside an C<if> block which itself is followed by
=item *
-Assignment to C<$^A> (the format output accumulator) now recalculates
-the number of lines output.
-
-=item *
-
-Locking a subroutine (via C<lock &sub>) is no longer a compile-time error
-for regular subs. For lvalue subroutines, it no longer tries to return the
-sub as a scalar, resulting in strange side effects like C<ref \$_>
-returning "CODE" in some instances.
-
-C<lock &sub> is now a run-time error if L<threads::shared> is loaded (a
-no-op otherwise), but that may be rectified in a future version.
-
-=item *
-
-The prototypes of several built-in functions--C<getprotobynumber>, C<lock>,
-C<not> and C<select>--have been corrected, or at least are now closer to
-reality than before.
-
-=item *
-
Infinite loops like C<1 while 1> used to stop C<strict 'subs'> mode from
working for the rest of the block.t
For list assignments like C<($a,$b) = ($b,$a)>, Perl has to make a copy of
the items on the right-hand side before assignment them to the left. For
efficiency's sake, it assigns the values on the right straight to the items
-on the left no variable is mentioned on both sides, as in
-C<($a,$b) = ($c,$d)>. The logic for determining when it can cheat was
-faulty, in that C<&&> and C<||> on the right-hand side could fool it. So
-C<($a,$b) = $some_true_value && ($b,$a)> would end up assigning the value
-of C<$b> to both scalars.
+on the left if no one variable is mentioned on both sides, as in C<($a,$b) =
+($c,$d)>. The logic for determining when it can cheat was faulty, in that
+C<&&> and C<||> on the right-hand side could fool it. So C<($a,$b) =
+$some_true_value && ($b,$a)> would end up assigning the value of C<$b> to
+both scalars.
=item *
=item *
-C<defined(${"..."})>, C<defined(*{"..."})>, etc., used to
-return true for most, but not all built-in variables, if
-they had not been used yet. Many times that new built-in
-variables were added in past versions, this construct was
-not taken into account, so this affected C<${^GLOBAL_PHASE}> and
-C<${^UTF8CACHE}>, among others. It also used to return false if the
-package name was given as well (C<${"::!"}>) [perl #97978, #97492].
-
-=item *
-
-Perl 5.10.0 introduced a similar bug: C<defined(*{"foo"})> where "foo"
-represents the name of a built-in global variable used to return false if
-the variable had never been used before, but only on the I<first> call.
-This, too, has been fixed.
-
-=item *
-
C<close> and similar filehandle functions, when called on built-in global
variables (like C<$+>), used to die if the variable happened to hold the
undefined value, instead of producing the usual "Use of uninitialized
=item *
-Since 5.6.0, C<*{ ... }> has been inconsistent in how it treats undefined
-values. It would die in strict mode or lvalue context for most undefined
-values, but would be treated as the empty string (with a warning) for the
-specific scalar return by C<undef()> (C<&PL_sv_undef> internally). This
-has been corrected. C<undef()> is now treated like other undefined
-scalars, as in Perl 5.005.
-
-=item *
-
C<setpgrp($foo)> used to be equivalent to C<($foo, setpgrp)>, because
C<setpgrp> was ignoring its argument if there was just one. Now it is
equivalent to C<setpgrp($foo,0)>.
=item *
-If things were arranged in memory the right way, it was possible for
-thread joining to emit "Attempt to free unreferenced scalar" warnings if
-C<caller> had been used from the C<DB> package prior to thread creation,
-due to the way pads were reference-counted and cloned [perl #98092].
-
-=item *
-
-C<given> was not scoping its implicit $_ properly, resulting in memory
-leaks or "Variable is not available" warnings [perl #94682].
-
-=item *
-
C<shmread> was not setting the scalar flags correctly when reading from
shared memory, causing the existing cached numeric representation in the
scalar to persist [perl #98480].
=item *
C<< die; >> with a non-reference, non-string, or magical (e.g., tainted)
-value in $@ now properly
-propagates that value [perl #111654].
+value in $@ now properly propagates that value [perl #111654].
=back
=item *
-L<Encode::JP::Mobile> version 0.27
-
-=item *
-
L<Module::CPANTS::Analyse> version 0.85
This fails due to problems in L<Module::Find> 0.10 and L<File::MMagic>
=back
-=head1 Obituary
-
-XXX If any significant core contributor has died, we've added a short obituary
-here.
-
=head1 Acknowledgements
XXX Generate this with:
https://perl5.git.perl.org / perl5.git / blobdiff