In perl.git, the branch blead has been updated <http://perl5.git.perl.org/perl.git/commitdiff/22ae2565cb9a5870e728da396f63b3e692d53231?hp=61f055fdc1637ca101b78de847a04564ff6fd206>
- Log ----------------------------------------------------------------- commit 22ae2565cb9a5870e728da396f63b3e692d53231 Author: Father Chrysostomos <[email protected]> Date: Sat Apr 21 06:37:25 2012 -0700 perl5160delta: More stuff I squashed three commits by mistake, and it wasnât worth separ- ating them: 1. Revamp substr revamp Move the bugs to the bugs section. Nobody cares about the order of uninit warnings, so zap that. 2. Fix pod syntax error 3. New section for given bugs M Porting/perl5160delta.pod commit fbd7c082aea94a9bfab4a2777619651d576e6c9f Author: Father Chrysostomos <[email protected]> Date: Sat Apr 21 06:28:37 2012 -0700 perl5160delta: New thread bug fix section M Porting/perl5160delta.pod commit 4fad228f56b47c43ce23a061912afeeee5b184d0 Author: Father Chrysostomos <[email protected]> Date: Sat Apr 21 06:25:31 2012 -0700 perl5160delta: New deref bug fix section M Porting/perl5160delta.pod commit 8dd333f3f0056821bd14f0bcb00ec13c05ce4760 Author: Father Chrysostomos <[email protected]> Date: Sat Apr 21 06:21:14 2012 -0700 perl5160delta: Another format bug M Porting/perl5160delta.pod commit 1c6fad2de3c98b7a34405d293598fa8c069ffde0 Author: Father Chrysostomos <[email protected]> Date: Sat Apr 21 06:20:17 2012 -0700 perl5160delta: Another regexp bug Itâs not specific to regexps, but itâs close enough. M Porting/perl5160delta.pod commit 7aa7425a2dbd5435c143492f708111520f1d1fac Author: Father Chrysostomos <[email protected]> Date: Sat Apr 21 06:18:43 2012 -0700 perl5160delta: Rmv #88138 This is more-or-less covered by the embedded nulls section. I canât see how to get the bug number in there in a way that is not misleading. M Porting/perl5160delta.pod commit fb83b88487649f5ba949641d6e9d96aebb31e39e Author: Father Chrysostomos <[email protected]> Date: Sat Apr 21 06:16:04 2012 -0700 perl5160delta: Another XS bug M Porting/perl5160delta.pod commit d38c78ed0a644e112f1bf8a786aa33c9aee0d938 Author: Father Chrysostomos <[email protected]> Date: Sat Apr 21 06:14:43 2012 -0700 perl5160delta: Another XS bug M Porting/perl5160delta.pod commit 8b80cdcfdd8372d2e845a67e51df69a203abd082 Author: Father Chrysostomos <[email protected]> Date: Sat Apr 21 06:13:51 2012 -0700 perl5160delta: Combine 2 similar return bugs M Porting/perl5160delta.pod commit 3c8a1310ef65868fec94730687d7b7b1a643e9a8 Author: Father Chrysostomos <[email protected]> Date: Sat Apr 21 06:10:38 2012 -0700 perl5160delta: Combine 2 similar $_ bugs M Porting/perl5160delta.pod commit 10ba0d3134fe8f0269c29c2d946c58066411a217 Author: Father Chrysostomos <[email protected]> Date: Sat Apr 21 06:05:17 2012 -0700 perl5160delta: new prototype bug fix section M Porting/perl5160delta.pod ----------------------------------------------------------------------- Summary of changes: Porting/perl5160delta.pod | 379 ++++++++++++++++++++++----------------------- 1 files changed, 186 insertions(+), 193 deletions(-) diff --git a/Porting/perl5160delta.pod b/Porting/perl5160delta.pod index bc11968..41224da 100644 --- a/Porting/perl5160delta.pod +++ b/Porting/perl5160delta.pod @@ -82,7 +82,7 @@ See L<feature> for more detail. =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 @@ -98,11 +98,7 @@ lvalue scalar that is returned, and the original string is not even 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 @@ -118,42 +114,9 @@ The same thing happens with an omitted third argument. The returned 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> @@ -2001,6 +1964,12 @@ 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(). + =back =head2 Formats @@ -2021,6 +1990,11 @@ 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 * + +Assignment to C<$^A> (the format output accumulator) now recalculates +the number of lines output. + =back =head2 Copy-on-write scalars @@ -2930,6 +2904,151 @@ variable [perl #98662]. =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 Bugs involving the dereferencing operators + +=over + +=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. 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 * + +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 * + +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. + +=back + +=head2 Threading bugs + +=over + +=item * + +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 * + +Some cases of threads crashing due to memory allocation during cloning have +been fixed [perl #90006]. + +=item * + +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 * + +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. + +=back + +=head2 Fixes to C<given> and C<when> + +=over + +=item * + +C<given> was not scoping its implicit $_ properly, resulting in memory +leaks or "Variable is not available" warnings [perl #94682]. + +=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 * + +C<when> blocks are now capable of returning variables declared inside the +enclosing C<given> block [perl #93548]. + +=back + +=head2 Fixes to 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 + =head2 Fixes affecting the C API =over @@ -2962,6 +3081,21 @@ C<SvPVutf8> now works properly with magical variables. C<SvPVbyte> now works properly non-PVs. +=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 * + +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]. + =back =head2 Other notable fixes @@ -3041,14 +3175,6 @@ nonexistent hash and array elements [perl #3471, #103492]. =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 @@ -3058,14 +3184,13 @@ variable. This has been fixed [perl #105912]. =item * -Returning tied variables +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]. -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 * @@ -3073,10 +3198,10 @@ C<utf8::decode> now refuses to modify read-only scalars [perl #91850]. =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]. +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 * @@ -3109,15 +3234,6 @@ 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]: @@ -3132,12 +3248,6 @@ repeat counts [perl #94560]. =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]. @@ -3206,13 +3316,6 @@ 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 from when parsing a here document [perl #90128]. (5.14.1) @@ -3223,57 +3326,6 @@ inside a C<while> condition [perl #90888]. =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 @@ -3286,27 +3338,6 @@ subsequently compiled code to become tainted [perl #64804]. =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 @@ -3338,23 +3369,6 @@ was triggering this bug [perl #97010]. =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 @@ -3379,33 +3393,12 @@ results in a crash [perl #93320]. =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]. -- Perl5 Master Repository
