In perl.git, the branch blead has been updated <http://perl5.git.perl.org/perl.git/commitdiff/ad275677c817a644a9045aaa3a48c604d073cf40?hp=f374360c52233c7d72ba874294a00ee18d910d08>
- Log ----------------------------------------------------------------- commit ad275677c817a644a9045aaa3a48c604d073cf40 Author: Father Chrysostomos <[email protected]> Date: Fri Apr 20 23:09:25 2012 -0700 perl5160delta: New debugger bug fix section M Porting/perl5160delta.pod commit fdf8c80924dc9885471ee295d44d578b200613c6 Author: Father Chrysostomos <[email protected]> Date: Fri Apr 20 23:02:11 2012 -0700 perl5160delta: New sort bug fix section M Porting/perl5160delta.pod commit 78c5646a4414a2ef09c22ced24a2ee293ecd5b3c Author: Father Chrysostomos <[email protected]> Date: Fri Apr 20 22:57:32 2012 -0700 perl5160delta: New overloading bug fix section M Porting/perl5160delta.pod commit b69c108d5afcdd5bb1580de99ba936eb4a2899c7 Author: Father Chrysostomos <[email protected]> Date: Fri Apr 20 22:55:34 2012 -0700 perl5160delta: Donât mention Internals::SvREFCNT It officially doesnât exist. :-) M Porting/perl5160delta.pod commit 9c00207691b57e06d2e1353adf955009c6e20851 Author: Father Chrysostomos <[email protected]> Date: Fri Apr 20 22:54:16 2012 -0700 perl5160delta: Rmv debugger local $_ thing This entry is no longer relevant, now that local $_ is fixed. M Porting/perl5160delta.pod commit 288a601f2d2b57fa203b59d2ff26ad16557418dc Author: Father Chrysostomos <[email protected]> Date: Fri Apr 20 22:54:06 2012 -0700 perl5160delta: New section for redef warnings M Porting/perl5160delta.pod commit 891b15756bd06b88f12ace2a9e5bed6394f5662a Author: Father Chrysostomos <[email protected]> Date: Fri Apr 20 17:51:36 2012 -0700 perl5160delta: Rmv null-named const bug This is covered by the section on embedded nulls. This was only listed separately because it came later. M Porting/perl5160delta.pod commit b77d6b937c0f8cee201cddcc8a8214197bbc102f Author: Father Chrysostomos <[email protected]> Date: Fri Apr 20 17:50:41 2012 -0700 perl5160delta: Move more re fixes to the re section M Porting/perl5160delta.pod commit edc1ae43fb4b788c7b02b300728b7b9423a97b58 Author: Father Chrysostomos <[email protected]> Date: Fri Apr 20 17:46:45 2012 -0700 perl5160delta: Separate section for PL_last_in_gv fixes M Porting/perl5160delta.pod commit 5290772f38866aa917d2439945a0025bbb73de15 Author: Father Chrysostomos <[email protected]> Date: Fri Apr 20 17:41:25 2012 -0700 perl5160delta: Move more COW stuff into the COW section M Porting/perl5160delta.pod commit b81fe5e9d918e1098852fd25eb2d3a0dc4e5aa4d Author: Father Chrysostomos <[email protected]> Date: Fri Apr 20 16:38:18 2012 -0700 perl5160delta: Make an uninit warning bug fix section M Porting/perl5160delta.pod ----------------------------------------------------------------------- Summary of changes: Porting/perl5160delta.pod | 705 +++++++++++++++++++++++---------------------- 1 files changed, 355 insertions(+), 350 deletions(-) diff --git a/Porting/perl5160delta.pod b/Porting/perl5160delta.pod index 17b3ab6..2941baa 100644 --- a/Porting/perl5160delta.pod +++ b/Porting/perl5160delta.pod @@ -1804,6 +1804,8 @@ All the C files that make up the Perl core have been converted to UTF-8. =head2 Regular expressions and character classes +XXX Is it possible to merge some of these items? + =over 4 =item * @@ -1891,6 +1893,99 @@ 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]. + =back =head2 Formats @@ -1915,7 +2010,8 @@ passing a reference to C<formline> no longer destroys the reference =head2 Copy-on-write scalars -Copy-on-write scalars were introduced in 5.8.0, but most Perl code +Copy-on-write or shared hash key scalars +were introduced in 5.8.0, but most Perl code did not encounter them (they were used mostly internally). Perl 5.10.0 extended them, such that assigning C<__PACKAGE__> or a hash key to a scalar would make it copy-on-write. Several parts @@ -1948,6 +2044,29 @@ copy-on-write string. =item * +Assigning a copy-on-write string to a stash +element no longer causes a double free. Regardless of this change, the +results of such assignments are still undefined. + +=item * + +Assigning a copy-on-write string to a tied variable no longer stops that +variable from being tied if it happens to be a PVMG or PVLV internally. + +=item * + +Doing a substitution on a tied variable returning a copy-on-write +scalar used to cause an assertion failure or an "Attempt to free +nonexistent shared string" warning. + +=item * + +This one is a regression from 5.12: In 5.14.0, the bitwise assignment +operators C<|=>, C<^=> and C<&=> started leaving the left-hand side +undefined if it happened to be a copy-on-write string [perl #108480]. + +=item * + L<Storable>, L<Devel::Peek> and L<PerlIO::scalar> had similar problems. See L</Updated Modules and Pragmata>, above. @@ -2520,7 +2639,7 @@ in Perl 5.10.0. For typeglobs, it has probably never worked till now. =back -=head2 Other notable fixes +=head2 "Uninitialized" warnings =over @@ -2532,12 +2651,39 @@ Various functions that take a filehandle argument in rvalue context =item * -Last-accessed filehandle +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]. + +=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]. + +=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 + +=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 @@ -2552,340 +2698,341 @@ 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. -=item * - -C<~~> now correctly handles the precedence of Any~~Object, and is not tricked -by an overloaded object on the left-hand side. +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 * -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 -infamous L<perlunicode/The "Unicode Bug">. [perl #77654]. +A regression in 5.14 caused these statements not to set that internal +variable: -Which of these code points is quoted has changed, based on Unicode's -recommendations. See L<perlfunc/quotemeta> for details. + my $fh = *STDOUT; + tell $fh; + eof $fh; + seek $fh, 0,0; + tell *$fh; + eof *$fh; + seek *$fh, 0,0; + readline *$fh; -=item * +This is now fixed, but C<tell *{ *$fh }> still has the problem, and it +is not clear how to fix it [perl #106536]. -C<newHVhv> and tied hashes +=back -The C<newHVhv> XS function now works on tied hashes, instead of crashing or -returning an empty hash. +=head2 Redefinition warnings -=item * +=over -No warning for C<open(foo::bar)> +=item * -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 -has been corrected. +Subroutines from the C<autouse> namespace are once more exempt from +redefinition warnings. This used to work in 5.005, but was broken in +5.6 for most subroutines. For subs created via XS that redefine +subroutines from the C<autouse> package, this stopped working in 5.10. =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 -was selected. Now it returns a typeglob reference in such cases. +New XSUBs now produce redefinition warnings if they overwrite existing +subs, as they did in 5.8.x. (The C<autouse> logic was reversed in +5.10-14. Only subroutines from the C<autouse> namespace would warn +when clobbered.) =item * -C<PerlIO::get_layers> and numbers +C<newCONSTSUB> used to use compile-time warning hints, instead of +run-time hints. The following code should never produce a redefinition +warning, but it used to, if C<newCONSTSUB> redefined an existing +subroutine: -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). + use warnings; + BEGIN { + no warnings; + some_XS_function_that_calls_new_CONSTSUB(); + } =item * -Unrecognised switches on C<#!> line +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. -If a switch, such as B<-x>, that cannot occur on the C<#!> line is used -there, perl dies with "Can't emulate...". +=item * -It used to produce the same message for switches that perl did not -recognise at all, whether on the command line or the C<#!> line. +The internal check to see whether a redefinition warning should occur +used to emit "uninitialized" warnings in cases like this: -Now it produces the "Unrecognized switch" error message [perl #104288]. + use warnings "uninitialized"; + use constant {u => undef, v => undef}; + sub foo(){u} + sub foo(){v} -=item * +=back -C<system> and SIGCHLD +=head2 Overloading -C<system> now temporarily blocks the SIGCHLD signal handler, to prevent the -signal handler from stealing the exit status [perl #105700]. +=over =item * -C<(s)printf>'s %n formatting code +Arithmetic assignment (C<$left += $right>) involving overloaded objects +that rely on the 'nomethod' override no longer segfault when the left +operand is not overloaded. -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 -assigns the number of characters, instead of the number of bytes. +=item * -It also works now with special lvalue functions like C<substr> and with -nonexistent hash and array elements [perl #3471, #103492]. +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 * -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]. +Undefining C<%overload::> no longer causes a crash. -=item * +=back -C<local $_> +=head2 Fixes to the C<sort> operator -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]. +=over =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]. +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<utf8::decode> now refuses to modify read-only scalars [perl #91850]. +C<sort> now works once more with custom sort routines that are XSUBs. It +stopped working in 5.10.0. =item * -C<dbmopen> with undefined mode - -C<dbmopen> now only warns once, rather than three times, if the mode -argument is C<undef> [perl #90064]. +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 * -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]. +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 * -Warnings with C<+=> - -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]. +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]. -=item * +=back -C<@&> and C<$&> +=head2 Fixes affecting the debugger -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]. +=over =item * -Bitwise assignment operators and copy-on-write +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 * -In 5.14.0, the bitwise assignment operators C<|=>, C<^=> and C<&=> started -leaving the left-hand side undefined if it happened to be a copy-on-write -string. This has been fixed [perl #108480]. +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 * -Three problematic Unicode characters now work better in regex pattern matching under C</i> +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. -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]. +=item * -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]. +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 * -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: +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]. - for (1..10_000_000) { - if ("foo" =~ /(foo|(?<capture>bar))?/) { - my $capture = $+{capture} - } - } - system "ps -o rss $$"' +=back -=item * +=head2 Other notable fixes -A constant subroutine assigned to a glob whose name contains a null -will no longer cause extra globs to pop into existence when the -constant is referenced under its new name. +=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 {()}>. +C<~~> now correctly handles the precedence of Any~~Object, and is not tricked +by an overloaded object on the left-hand side. =item * -Subroutines from the C<autouse> namespace are once more exempt from -redefinition warnings. This used to work in 5.005, but was broken in -5.6 for most subroutines. For subs created via XS that redefine -subroutines from the C<autouse> package, this stopped working in 5.10. +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 +infamous L<perlunicode/The "Unicode Bug">. [perl #77654]. + +Which of these code points is quoted has changed, based on Unicode's +recommendations. See L<perlfunc/quotemeta> for details. =item * -New XSUBs now produce redefinition warnings if they overwrite existing -subs, as they did in 5.8.x. (The C<autouse> logic was reversed in -5.10-14. Only subroutines from the C<autouse> namespace would warn -when clobbered.) +C<newHVhv> and tied hashes + +The C<newHVhv> XS function now works on tied hashes, instead of crashing or +returning an empty hash. =item * -C<newCONSTSUB> used to use compile-time warning hints, instead of -run-time hints. The following code should never produce a redefinition -warning, but it used to, if C<newCONSTSUB> redefined an existing -subroutine: +No warning for C<open(foo::bar)> - use warnings; - BEGIN { - no warnings; - some_XS_function_that_calls_new_CONSTSUB(); - } +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 +has been corrected. =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. +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 +was selected. Now it returns a typeglob reference in such cases. =item * -The internal check to see whether a redefinition warning should occur -used to emit "uninitialized" warnings in cases like this: +C<PerlIO::get_layers> and numbers - use warnings "uninitialized"; - use constant {u => undef, v => undef}; - sub foo(){u} - sub foo(){v} +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 * -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]. +Unrecognised switches on C<#!> line + +If a switch, such as B<-x>, that cannot occur on the C<#!> line is used +there, perl dies with "Can't emulate...". + +It used to produce the same message for switches that perl did not +recognise at all, whether on the command line or the C<#!> line. + +Now it produces the "Unrecognized switch" error message [perl #104288]. =item * -Return value of C<eval> +C<system> and SIGCHLD -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 -list containing a single undefined element. Now it returns an empty -list in list context for all errors [perl #80630]. +C<system> now temporarily blocks the SIGCHLD signal handler, to prevent the +signal handler from stealing the exit status [perl #105700]. =item * -C<goto &func> no longer crashes, but produces an error message, when -the unwinding of the current subroutine's scope fires a destructor that -undefines the subroutine being "goneto" [perl #99850]. +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 +assigns the number of characters, instead of the number of bytes. + +It also works now with special lvalue functions like C<substr> and with +nonexistent hash and array elements [perl #3471, #103492]. =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. +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 * -Assigning C<__PACKAGE__> or any other shared hash key scalar to a stash -element no longer causes a double free. Regardless of this change, the -results of such assignments are still undefined. +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 * -Assigning C<__PACKAGE__> or another shared hash key string to a -variable no longer stops that variable from being tied if it happens to -be a PVMG or PVLV internally. +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]. =item * -Creating a C<UNIVERSAL::AUTOLOAD> sub no longer stops C<%+>, C<%-> and -C<%!> from working some of the time [perl #105024]. +C<utf8::decode> now refuses to modify read-only scalars [perl #91850]. =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. +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 * -Doing a substitution on a tied variable returning a copy-on-write -scalar used to cause an assertion failure or an "Attempt to free -nonexistent shared string" warning. +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]. =item * -The debugger no longer tries to do C<local $_> when dumping data -structures. +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 +list containing a single undefined element. Now it returns an empty +list in list context for all errors [perl #80630]. =item * -Calling C<readline($fh)> where $fh is a glob copy (e.g., after C<$fh = -*STDOUT>), assigning something other than a glob to $fh, and then -freeing $fh (e.g., by leaving the scope where it is defined) no longer -causes the internal variable used by C<$.> (C<PL_last_in_gv>) to point -to a freed scalar, that could be reused for some other glob, causing -C<$.> to use some unrelated filehandle [perl #97988]. +C<goto &func> no longer crashes, but produces an error message, when +the unwinding of the current subroutine's scope fires a destructor that +undefines the subroutine being "goneto" [perl #99850]. =item * -A regression in 5.14 caused these statements not to set the internal -variable that holds the handle used by C<$.>: +Creating a C<UNIVERSAL::AUTOLOAD> sub no longer stops C<%+>, C<%-> and +C<%!> from working some of the time [perl #105024]. - my $fh = *STDOUT; - tell $fh; - eof $fh; - seek $fh, 0,0; - tell *$fh; - eof *$fh; - seek *$fh, 0,0; - readline *$fh; +=item * -This is now fixed, but C<tell *{ *$fh }> still has the problem, and it -is not clear how to fix it [perl #106536]. +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 * @@ -2898,12 +3045,6 @@ currently compiling in. This means that the following code no longer crashes [p =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 C<x> repetition operator no longer crashes on 64-bit builds with large repeat counts [perl #94560]. @@ -2928,60 +3069,12 @@ used to respect overrides, despite the C<CORE::> prefix. =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 * - 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 * -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 * - -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 * - -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 * - -Warnings emitted by C<sort> when a custom comparison routine returns a -non-numeric value now 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<Internals::SvREFCNT> now behaves consistently in 'get' and 'set' scenarios -[perl #103222] and also treats the reference count as unsigned. - -=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]. @@ -3000,29 +3093,12 @@ the caller's scope (enabled by L<open.pm|open>) [perl #96008]. =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. - -=item * - C<our $::é; $é> (which is invalid) no longer produces the "Compilation error at lib/utf8_heavy.pl..." error message, which it started emitting in 5.10.0 [perl #99984]. =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 * - On 64-bit systems, C<read()> now understands large string offsets beyond the 32-bit range. @@ -3033,34 +3109,6 @@ subroutine's op tree to leak. =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 produced when a custom sort routine returns a non-numeric value -now contain "in sort"; e.g., "Use of uninitialized value in sort". - -=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]. - -=item * - -C<..> and C<...> in list context now mention the name of the variable in -"uninitialized" warnings for string (as opposed to numeric) ranges. - -=item * - Passing the same constant subroutine to both C<index> and C<formline> no longer causes one or the other to fail [perl #89218]. (5.14.1) @@ -3102,12 +3150,6 @@ different variable [perl #84526]. =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 * - Fixed a case where it was possible that a freed buffer may have been read from when parsing a here document [perl #90128]. (5.14.1) @@ -3218,11 +3260,6 @@ the number of lines output. =item * -The regexp optimiser no longer crashes on debugging builds when merging -fixed-string nodes with inconvenient contents. - -=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 \$_> @@ -3239,21 +3276,6 @@ reality than before. =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 * - Infinite loops like C<1 while 1> used to stop C<strict 'subs'> mode from working for the rest of the block.t @@ -3285,13 +3307,6 @@ to force it [perl #96942]. =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]. - -=item * - C<caller> no longer leaks memory when called from the DB package if C<@DB::args> was assigned to after the first call to C<caller>. L<Carp> was triggering this bug [perl #97010]. @@ -3413,20 +3428,10 @@ started [perl #37033]. =item * -C<< (?foo: ...) >> no longer loses passed in character set. - -=item * - C<< die; >> with a non-reference, non-string, or magical (e.g., tainted) value in $@ now properly propagates that value [perl #111654]. -=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]. - =back =head1 Known Problems -- Perl5 Master Repository
