From 61752d82e203965b9c2fa921225aa79422113d2a Mon Sep 17 00:00:00 2001 From: Father Chrysostomos Date: Mon, 14 Mar 2011 18:19:01 -0700 Subject: [PATCH] perldelta: Rearrange and categorise Incompatible Changes --- pod/perldelta.pod | 408 ++++++++++++++++++++++++++++-------------------------- 1 file changed, 212 insertions(+), 196 deletions(-) diff --git a/pod/perldelta.pod b/pod/perldelta.pod index 9b00320..67952b4 100644 --- a/pod/perldelta.pod +++ b/pod/perldelta.pod @@ -472,71 +472,18 @@ user-defined. It simply dies instead [perl #82616]. =head1 Incompatible Changes -=head2 "C<\cI>" +Perl 5.14.0 is not binary-compatible with any previous stable release. + +=head2 Regular Expressions and String Escapes + +=head3 C<\cI> The backslash-c construct was designed as a way of specifying non-printable characters, but there were no restrictions (on ASCII platforms) on what the character following the C could be. Now, that character must be one of the ASCII characters. -=head2 Localised tied hashes and arrays are no longed tied - -In the following: - - tie @a, ...; - { - local @a; - # here, @a is a now a new, untied array - } - # here, @a refers again to the old, tied array - -The new local array used to be made tied too, which was fairly pointless, -and has now been fixed. This fix could however potentially cause a change -in behaviour of some code. - -=head2 C return values - -C blocks now return the last evaluated -expression, or an empty list if the block was exited by C. Thus you -can now write: - - my $type = do { - given ($num) { - break when undef; - 'integer' when /^[+-]?[0-9]+$/; - 'float' when /^[+-]?[0-9]+(?:\.[0-9]+)?$/; - 'unknown'; - } - }; - -See L for details. - -=head2 Naming fixes in Policy_sh.SH may invalidate Policy.sh - -Several long-standing typos and naming confusions in Policy_sh.SH have -been fixed, standardizing on the variable names used in config.sh. - -This will change the behavior of Policy.sh if you happen to have been -accidentally relying on the Policy.sh incorrect behavior. - -=head2 Stashes are now always defined - -C now always returns true, even when no symbols have yet been -defined in that package. - -This is a side effect of removing a special case kludge in the tokeniser, -added for 5.10.0, to hide side effects of changes to the internal storage of -hashes that drastically reduce their memory usage overhead. - -Calling defined on a stash has been deprecated since 5.6.0, warned on -lexicals since 5.6.0, and warned for stashes (and other package -variables) since 5.12.0. C has always exposed an -implementation detail - emptying a hash by deleting all entries from it does -not make C false, hence C is not valid code to -determine whether an arbitrary hash is empty. Instead, use the behaviour -that an empty C<%hash> always returns false in a scalar context. - -=head2 \400 - \777 +=head3 \400 - \777 Use of C<\400> - C<\777> in regexes in certain circumstances has given different, anomalous behavior than their use in all other @@ -549,89 +496,51 @@ files whole; previously, this was documented only for C<"-0777">. It is recommended, however, because of various ambiguities, to use the new C<\o{...}> construct to represent characters in octal. -=head2 Check API compatibility when loading XS modules - -When perl's API changes in incompatible ways (which usually happens between -major releases), XS modules compiled for previous versions of perl will not -work anymore. They will need to be recompiled against the new perl. - -In order to ensure that modules are recompiled, and to prevent users from -accidentally loading modules compiled for old perls into newer ones, the -C macro has been added. That macro, which is called -when loading every newly compiled extension, compares the API version of the -running perl with the version a module has been compiled for and raises an -exception if they don't match. - -=head2 Binary-incompatible with all previous Perls - -Perl 5.14.0 is not binary-compatible with any previous stable release. - -=head2 Change in the parsing of certain prototypes - -Functions declared with the following prototypes now behave correctly as unary -functions: - - * - \$ \% \@ \* \& - \[...] - ;$ ;* - ;\$ ;\% etc. - ;\[...] - -Due to this bug fix [perl #75904], functions -using the C<(*)>, C<(;$)> and C<(;*)> prototypes -are parsed with higher precedence than before. So in the following example: - - sub foo($); - foo $a < $b; - -the second line is now parsed correctly as C<< foo($a) < $b >>, rather than -C<< foo($a < $b) >>. This happens when one of these operators is used in -an unparenthesised argument: - - < > <= >= lt gt le ge - == != <=> eq ne cmp ~~ - & - | ^ - && - || // - .. ... - ?: - = += -= *= etc. - -=head2 Magic variables outside the main package +=head3 Most C<\p{}> properties are now immune to case-insensitive matching -In previous versions of Perl, magic variables like C<$!>, C<%SIG>, etc. would -'leak' into other packages. So C<%foo::SIG> could be used to access signals, -C<${"foo::!"}> (with strict mode off) to access C's C, etc. +For most Unicode properties, it doesn't make sense to have them match +differently under C case-insensitive matching than not. And doing +so leads to unexpected results and potential security holes. For +example -This was a bug, or an 'unintentional' feature, which caused various ill effects, -such as signal handlers being wiped when modules were loaded, etc. + m/\p{ASCII_Hex_Digit}+/i -This has been fixed (or the feature has been removed, depending on how you see -it). +could previously match non-ASCII characters because of the Unicode +matching rules. There were a number of bugs in this feature until an +earlier release in the 5.13 series. Now this release reverts, and +removes the feature completely except for the few properties where +people have come to expect it, namely the ones where casing is an +integral part of their functionality, such as C and +C, both of which match the exact same code points, +namely those matched by C. Details are in +L. -=head2 Smart-matching against array slices +XXX The mention of ‘until an earlier release in the 5.13 series’ needs to +change, but I do not fully understand what happened here. -Previously, the following code resulted in a successful match: +User-defined property handlers that need to match differently under +C must change to read the new boolean parameter passed to it which is +non-zero if case-insensitive matching is in effect or 0 otherwise. See +L. - my @a = qw(a y0 z); - my @b = qw(a x0 z); - @a[0 .. $#b] ~~ @b; +=head3 \p{} implies Unicode semantics -This odd behaviour has now been fixed [perl #77468]. +Now, a Unicode property match specified in the pattern will indicate +that the pattern is meant for matching according to Unicode rules, the way +C<\x{}> does. -=head2 C API changes +=head3 Regular expressions retain their localeness when interpolated -The first argument of the C API function C has changed -from C to C, to better insulate the user from -implementation details. +Regular expressions compiled under C<"use locale"> now retain this when +interpolated into a new regular expression compiled outside a +C<"use locale">, and vice-versa. -This API function was marked as "may change", and likely isn't in use outside -the core. (Neither an unpacked CPAN, nor Google's codesearch, finds any other -references to it.) +Previously, a regular expression interpolated into another one inherited +the localeness of the surrounding one, losing whatever state it +originally had. This is considered a bug fix, but may trip up code that +has come to rely on the incorrect behavior. -=head2 Stringification of regexes has changed +=head3 Stringification of regexes has changed Default regular expression modifiers are now notated by using C<(?^...)>. Code relying on the old stringification will fail. The @@ -653,37 +562,54 @@ supported, you can use something like the following: And then use C<$modifiers> instead of C<-xism>. -=head2 Regular expressions retain their localeness when interpolated +=head3 Run-time code blocks in regular expressions inherit pragmata -Regular expressions compiled under C<"use locale"> now retain this when -interpolated into a new regular expression compiled outside a -C<"use locale">, and vice-versa. +Code blocks in regular expressions (C<(?{...})> and C<(??{...})>) used not +to inherit any pragmata (strict, warnings, etc.) if the regular expression +was compiled at run time as happens in cases like these two: -Previously, a regular expression interpolated into another one inherited -the localeness of the surrounding one, losing whatever state it -originally had. This is considered a bug fix, but may trip up code that -has come to rely on the incorrect behavior. + use re 'eval'; + $foo =~ $bar; # when $bar contains (?{...}) + $foo =~ /$bar(?{ $finished = 1 })/; -=head2 Directory handles not copied to threads +This was a bug, which has now been fixed. But it has the potential to break +any code that was relying on it. -On systems that do not have a C function, newly-created threads no -longer inherit directory handles from their parent threads. Such programs -would probably have crashed anyway [perl #75154]. +=head2 Stashes and Package Variables -=head2 Negation treats strings differently from before +=head3 Localised tied hashes and arrays are no longed tied -The unary negation operator C<-> now treats strings that look like numbers -as numbers [perl #57706]. +In the following: -=head2 Negative zero + tie @a, ...; + { + local @a; + # here, @a is a now a new, untied array + } + # here, @a refers again to the old, tied array -Negative zero (-0.0), when converted to a string, now becomes "0" on all -platforms. It used to become "-0" on some, but "0" on others. +The new local array used to be made tied too, which was fairly pointless, +and has now been fixed. This fix could however potentially cause a change +in behaviour of some code. -If you still need to determine whether a zero is negative, use -C or the L module on CPAN. +=head3 Stashes are now always defined -=head2 Dereferencing typeglobs +C now always returns true, even when no symbols have yet been +defined in that package. + +This is a side effect of removing a special case kludge in the tokeniser, +added for 5.10.0, to hide side effects of changes to the internal storage of +hashes that drastically reduce their memory usage overhead. + +Calling defined on a stash has been deprecated since 5.6.0, warned on +lexicals since 5.6.0, and warned for stashes (and other package +variables) since 5.12.0. C has always exposed an +implementation detail - emptying a hash by deleting all entries from it does +not make C false, hence C is not valid code to +determine whether an arbitrary hash is empty. Instead, use the behaviour +that an empty C<%hash> always returns false in a scalar context. + +=head3 Dereferencing typeglobs If you assign a typeglob to a scalar variable: @@ -704,7 +630,9 @@ assign C<\@some_array> to C<$glob>. To fix this, the C<*{}> operator (including the C<*foo> and C<*$foo> forms) has been modified to make a new immutable glob if its operand is a glob copy. Various operators that make a distinction between globs and scalars -have been modified to treat only immutable globs as globs. +have been modified to treat only immutable globs as globs. (C, +C and C has been left as they are for compatibility's sake, +but will warn. See L.) This causes an incompatible change in code that assigns a glob to the return value of C<*{}> when that operator was passed a glob copy. Take the @@ -724,7 +652,7 @@ and maybe others, too, have been fixed. See L for even more detail. -=head2 Clearing stashes +=head3 Clearing stashes Stash list assignment C<%foo:: = ()> used to make the stash anonymous temporarily while it was being emptied. Consequently, any of its @@ -733,7 +661,94 @@ subroutines referenced elsewhere would become anonymous (showing up as C will return the original sub name if there is still a reference to its typeglob, or "foo::__ANON__" otherwise [perl #79208]. -=head2 C<:=> is now a syntax error +=head3 Magic variables outside the main package + +In previous versions of Perl, magic variables like C<$!>, C<%SIG>, etc. would +'leak' into other packages. So C<%foo::SIG> could be used to access signals, +C<${"foo::!"}> (with strict mode off) to access C's C, etc. + +This was a bug, or an 'unintentional' feature, which caused various ill effects, +such as signal handlers being wiped when modules were loaded, etc. + +This has been fixed (or the feature has been removed, depending on how you see +it). + +=head2 Changes to Syntax or to Perl Operators + +=head3 C return values + +C blocks now return the last evaluated +expression, or an empty list if the block was exited by C. Thus you +can now write: + + my $type = do { + given ($num) { + break when undef; + 'integer' when /^[+-]?[0-9]+$/; + 'float' when /^[+-]?[0-9]+(?:\.[0-9]+)?$/; + 'unknown'; + } + }; + +See L for details. + +=head3 Change in the parsing of certain prototypes + +Functions declared with the following prototypes now behave correctly as unary +functions: + + * + \$ \% \@ \* \& + \[...] + ;$ ;* + ;\$ ;\% etc. + ;\[...] + +Due to this bug fix [perl #75904], functions +using the C<(*)>, C<(;$)> and C<(;*)> prototypes +are parsed with higher precedence than before. So in the following example: + + sub foo($); + foo $a < $b; + +the second line is now parsed correctly as C<< foo($a) < $b >>, rather than +C<< foo($a < $b) >>. This happens when one of these operators is used in +an unparenthesised argument: + + < > <= >= lt gt le ge + == != <=> eq ne cmp ~~ + & + | ^ + && + || // + .. ... + ?: + = += -= *= etc. + +=head3 Smart-matching against array slices + +Previously, the following code resulted in a successful match: + + my @a = qw(a y0 z); + my @b = qw(a x0 z); + @a[0 .. $#b] ~~ @b; + +This odd behaviour has now been fixed [perl #77468]. + +=head3 Negation treats strings differently from before + +The unary negation operator C<-> now treats strings that look like numbers +as numbers [perl #57706]. + +=head3 Negative zero + +Negative zero (-0.0), when converted to a string, now becomes "0" on all +platforms. It used to become "-0" on some, but "0" on others. + +If you still need to determine whether a zero is negative, use +C or the L module on CPAN. + +=head3 C<:=> is now a syntax error Previously C was exactly equivalent to C, with the C<:> being treated as the start of an attribute list, ending before @@ -748,53 +763,57 @@ If it is absolutely necessary to have empty attribute lists (for example, because of a code generator) then avoid the error by adding a space before the C<=>. -=head2 Run-time code block in regular expressions +=head2 Threads and Processes -Code blocks in regular expressions (C<(?{...})> and C<(??{...})>) used not -to inherit any pragmata (strict, warnings, etc.) if the regular expression -was compiled at run time as happens in cases like these two: +=head3 Directory handles not copied to threads - use re 'eval'; - $foo =~ $bar; # when $bar contains (?{...}) - $foo =~ /$bar(?{ $finished = 1 })/; +On systems other than Windows that do not have +a C function, newly-created threads no +longer inherit directory handles from their parent threads. Such programs +would usually have crashed anyway [perl #75154]. -This was a bug, which has now been fixed. But it has the potential to break -any code that was relying on this bug. +=head3 C on shared pipes -=head2 Most C<\p{}> properties are now immune from case-insensitive matching +The C function no longer waits for the child process to exit if the +underlying file descriptor is still in use by another thread, to avoid +deadlocks. It returns true in such cases. -For most Unicode properties, it doesn't make sense to have them match -differently under C case-insensitive matching than not. And doing -so leads to unexpected results and potential security holes. For -example +=head2 Configuration - m/\p{ASCII_Hex_Digit}+/i +=head3 Naming fixes in Policy_sh.SH may invalidate Policy.sh -could previously match non-ASCII characters because of the Unicode -matching rules. There were a number of bugs in this feature until an -earlier release in the 5.13 series. Now this release reverts, and -removes the feature completely except for the few properties where -people have come to expect it, namely the ones where casing is an -integral part of their functionality, such as C and -C, both of which match the exact same code points, -namely those matched by C. Details are in -L. +Several long-standing typos and naming confusions in Policy_sh.SH have +been fixed, standardizing on the variable names used in config.sh. -XXX The mention of ‘until an earlier release in the 5.13 series’ needs to -change, but I do not fully understand what happened here. +This will change the behavior of Policy.sh if you happen to have been +accidentally relying on the Policy.sh incorrect behavior. -User-defined property handlers that need to match differently under -C must change to read the new boolean parameter passed to it which is -non-zero if case-insensitive matching is in effect or 0 otherwise. See -L. +=head2 C API changes -=head2 regex: \p{} in pattern implies Unicode semantics +=head3 Check API compatibility when loading XS modules -Now, a Unicode property match specified in the pattern will indicate -that the pattern is meant for matching according to Unicode rules, the way -C<\x{}> does. +When perl's API changes in incompatible ways (which usually happens between +major releases), XS modules compiled for previous versions of perl will not +work anymore. They will need to be recompiled against the new perl. + +In order to ensure that modules are recompiled, and to prevent users from +accidentally loading modules compiled for old perls into newer ones, the +C macro has been added. That macro, which is called +when loading every newly compiled extension, compares the API version of the +running perl with the version a module has been compiled for and raises an +exception if they don't match. -=head2 GvCV() and GvGP() are no longer lvalues +=head3 Perl_fetch_cop_label + +The first argument of the C API function C has changed +from C to C, to better insulate the user from +implementation details. + +This API function was marked as "may change", and likely isn't in use outside +the core. (Neither an unpacked CPAN, nor Google's codesearch, finds any other +references to it.) + +=head3 GvCV() and GvGP() are no longer lvalues The new GvCV_set() and GvGP_set() macros are now provided to replace assignment to those two macros. @@ -803,12 +822,6 @@ This allows a future commit to eliminate some backref magic between GV and CVs, which will require complete control over assignment to the gp_cv slot. -=head2 C on shared pipes - -The C function no longer waits for the child process to exit if the -underlying file descriptor is still in use by another thread, to avoid -deadlocks. It returns true in such cases. - =head1 Deprecations The following items are now deprecated. @@ -2873,6 +2886,9 @@ less likely to get stuck in a mail queue somewhere. (019cfd2) =head1 Configuration and Compilation +See also L, +above. + =over 4 =item * -- 2.7.4