This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
perldelta: the incompatible changes section
authorRicardo Signes <rjbs@cpan.org>
Wed, 3 Apr 2013 01:14:43 +0000 (21:14 -0400)
committerRicardo Signes <rjbs@cpan.org>
Sun, 5 May 2013 19:32:20 +0000 (15:32 -0400)
Porting/perl5180delta.pod

index af72493..68b4f8e 100644 (file)
@@ -221,6 +221,24 @@ them is a bad idea.
 
 This vulnerability is documented in CVE-2012-6329.
 
+=head2 Avoid calling memset with a negative count
+
+Poorly written perl code that allows an attacker to specify the count to perl's
+C<x> string repeat operator can already cause a memory exhaustion
+denial-of-service attack. A flaw in versions of perl before 5.15.5 can escalate
+that into a heap buffer overrun; coupled with versions of glibc before 2.16, it
+possibly allows the execution of arbitrary code.
+
+The flaw addressed to this commit has been assigned identifier CVE-2012-5195
+and was researched by Tim Brown.
+
+=head1 Incompatible Changes
+
+=head2 See also: hash overhaul
+
+Some of the changes in the L<hash overhaul|/"Hash overhaul"> are not fully
+compatible with previous versions of perl.  Please read that section.
+
 =head2 An unknown character name in C<\N{...}> is now a syntax error
 
 Previously, it warned, and the Unicode REPLACEMENT CHARACTER was
@@ -241,37 +259,81 @@ such as in
 
 or to have commas anywhere in the name.  See L<charnames/CUSTOM ALIASES>
 
-=head2 Avoid calling memset with a negative count
-
-Poorly written perl code that allows an attacker to specify the count to perl's
-C<x> string repeat operator can already cause a memory exhaustion
-denial-of-service attack. A flaw in versions of perl before 5.15.5 can escalate
-that into a heap buffer overrun; coupled with versions of glibc before 2.16, it
-possibly allows the execution of arbitrary code.
-
-The flaw addressed to this commit has been assigned identifier CVE-2012-5195.
+=head2 C<\N{BELL}> now refers to U+1F514 instead of U+0007
 
-=head1 Incompatible Changes
+Unicode 6.0 reused the name "BELL" for a different code point than it
+traditionally had meant.  Since Perl v5.14, use of this name still
+referred to U+0007, but would raise a deprecation warning.  Now, "BELL"
+refers to U+1F514, and the name for U+0007 is "ALERT".  All the
+functions in L<charnames> have been correspondingly updated.
 
-=head2 See also: hash overhaul
+=head2 New Restrictions in Multi-Character Case-Insensitive Matching in Regular Expression Bracketed Character Classes
 
-Some of the changes in the L<hash overhaul|/"Hash overhaul"> are not fully
-compatible with previous versions of perl.  Please read that section.
+Unicode has now withdrawn their previous recommendation for regular
+expressions to automatically handle cases where a single character can
+match multiple characters case-insensitively; for example, the letter
+LATIN SMALL LETTER SHARP S and the sequence C<ss>.  This is because
+it turns out to be impracticable to do this correctly in all
+circumstances.  Because Perl has tried to do this as best it can, it
+will continue to do so.  (We are considering an option to turn it off.)
+However, a new restriction is being added on such matches when they
+occur in [bracketed] character classes.  People were specifying
+things such as C</[\0-\xff]/i>, and being surprised that it matches the
+two character sequence C<ss> (since LATIN SMALL LETTER SHARP S occurs in
+this range).  This behavior is also inconsistent with the using a
+property instead of a range:  C<\p{Block=Latin1}> also includes LATIN
+SMALL LETTER SHARP S, but C</[\p{Block=Latin1}]/i> does not match C<ss>.
+The new rule is that for there to be a multi-character case-insensitive
+match within a bracketed character class, the character must be
+explicitly listed, and not as an end point of a range.  This more
+closely obeys the Principle of Least Astonishment.  See
+L<perlrecharclass/Bracketed Character Classes>.  Note that a bug [perl
+#89774], now fixed as part of this change, prevented the previous
+behavior from working fully.
 
 =head2 Explicit rules for variable names and identifiers
 
 Due to an oversight, length-one variable names in 5.16 were completely
 unrestricted, and opened the door to several kinds of insanity.  As of
 5.18, these now follow the rules of other identifiers, in addition
-to accepting characters that match the \p{POSIX_Punct} property.
+to accepting characters that match the C<\p{POSIX_Punct}> property.
+
+There are no longer any differences in the parsing of identifiers
+specified as C<$...> or C<${...};> previously, they were dealt with in
+different parts of the core, and so had slightly different behavior. For
+instance, C<${foo:bar}> was a legal variable name.  Since they are now
+both parsed by the same code, that is no longer the case.
+
+=head2 C<\s> in regular expressions now matches a Vertical Tab
+
+No one could recall why C<\s> didn't match C<\cK>, the vertical tab.
+Now it does.  Given the extreme rarity of that character, very little
+breakage is expected.
+
+=head2 C</(?{})/> and C</(??{})/> have been heavily reworked
+
+The implementation of this feature has been almost completely rewritten.
+Although its main intent is to fix bugs, some behaviors, especially
+related to the scope of lexical variables, will have changed.  This is
+described more fully in the L</Selected Bug Fixes> section.
+
+=head2 Stricter parsing of substitution replacement
 
-There are no longer any differences in the parsing of identifiers specified
-as $... or ${...}; previously, they were dealt with in different parts of
-the core, and so had slightly different behavior. For instance,
-C<${foo:bar}> was a legal variable name.  Since they are now both parsed
-by the same code, that is no longer the case.
+It is no longer possible to abuse the way the parser parses C<s///e> like
+this:
+
+    %_=(_,"Just another ");
+    $_="Perl hacker,\n";
+    s//_}->{_/e;print
+
+=head2 C<given> now aliases the global C<$_>
+
+Instead of assigning to an implicit lexical C<$_>, C<given> now makes the
+global C<$_> an alias for its argument, just like C<foreach>.  However, it
+still uses lexical C<$_> if there is lexical C<$_> in scope (again, just like
+C<foreach>) [perl #114020].
 
-=head2 Lexical $_ is now deprecated
+=head2 Lexical $_ is now experimental
 
 Since it was introduced in Perl 5.10, it has caused much confusion with no
 obvious solution:
@@ -281,8 +343,8 @@ obvious solution:
 =item *
 
 Various modules (e.g., List::Util) expect callback routines to use the
-global $_.  C<use List::Util 'first'; my $_; first { $_ == 1 } @list> does
-not work as one would expect.
+global C<$_>.  C<use List::Util 'first'; my $_; first { $_ == 1 } @list>
+does not work as one would expect.
 
 =item *
 
@@ -292,21 +354,25 @@ warnings.
 =item *
 
 The "_" subroutine prototype character allows called subroutines to access
-your lexical $_, so it is not really private after all.
+your lexical C<$_>, so it is not really private after all.
 
 =item *
 
 Nevertheless, subroutines with a "(@)" prototype and methods cannot access
-the caller's lexical $_, unless they are written in XS.
+the caller's lexical C<$_>, unless they are written in XS.
 
 =item *
 
-But even XS routines cannot access a lexical $_ declared, not in the
+But even XS routines cannot access a lexical C<$_> declared, not in the
 calling subroutine, but in an outer scope, iff that subroutine happened not
-to mention $_ or use any operators that default to $_.
+to mention C<$_> or use any operators that default to C<$_>.
 
 =back
 
+It is our hope that lexical C<$_> can be rehabilitated, but this may
+cause changes in its behavior.  Please use it with caution until it
+becomes stable.
+
 =head2 readline() with C<$/ = \N> now reads N characters, not N bytes
 
 Previously, when reading from a stream with I/O layers such as
@@ -318,16 +384,6 @@ Now, I<N> characters are read instead.
 There is no change in behaviour when reading from streams with no
 extra layers, since bytes map exactly to characters.
 
-=head2 Lexical subroutine warnings have moved
-
-The warning about the use of an experimental feature emitted when lexical
-subroutines (added in 5.17.4) are used now happens when the subroutine
-itself is declared, not when the "lexical_subs" feature is activated via
-C<use feature>.
-
-This stops C<use feature ':all'> from warning, but causes
-C<my sub foo; my sub bar> to warn twice.
-
 =head2 Overridden C<glob> is now passed one argument
 
 C<glob> overrides used to be passed a magical undocumented second argument
@@ -335,30 +391,6 @@ that identified the caller.  Nothing on CPAN was using this, and it got in
 the way of a bug fix, so it was removed.  If you really need to identify
 the caller, see L<Devel::Callsite> on CPAN.
 
-=head2 New Restrictions in Multi-Character Case-Insensitive Matching in Regular Expression Bracketed Character Classes
-
-Unicode has now withdrawn their previous recommendation for regular
-expressions to automatically handle cases where a single character can
-match multiple characters case-insensitively; for example, the letter
-LATIN SMALL LETTER SHARP S and the sequence C<ss>.  This is because
-it turns out to be impracticable to do this correctly in all
-circumstances.  Because Perl has tried to do this as best it can, it
-will continue to do so.  (We are considering an option to turn it off.)
-However, a new restriction is being added on such matches when they
-occur in [bracketed] character classes.  People were specifying
-things such as C</[\0-\xff]/i>, and being surprised that it matches the
-two character sequence C<ss> (since LATIN SMALL LETTER SHARP S occurs in
-this range).  This behavior is also inconsistent with the using a
-property instead of a range:  C<\p{Block=Latin1}> also includes LATIN
-SMALL LETTER SHARP S, but C</[\p{Block=Latin1}]/i> does not match C<ss>.
-The new rule is that for there to be a multi-character case-insensitive
-match within a bracketed character class, the character must be
-explicitly listed, and not as an end point of a range.  This more
-closely obeys the Principle of Least Astonishment.  See
-L<perlrecharclass/Bracketed Character Classes>.  Note that a bug [perl
-#89774], now fixed as part of this change, prevented the previous
-behavior from working fully.
-
 =head2 Here-doc parsing
 
 The body of a here-document inside a quote-like operator now always begins
@@ -366,14 +398,33 @@ on the line after the "<<foo" marker.  Previously, it was documented to
 begin on the line following the containing quote-like operator, but that
 was only sometimes the case [perl #114040].
 
-=head2 Stricter parsing of substitution replacement
+=head2 Alphanumeric operators must now be separated from the closing
+delimiter of regular expressions
 
-It is no longer possible to abuse the way the parser parses C<s///e> like
-this:
+You may no longer write something like:
 
-    %_=(_,"Just another ");
-    $_="Perl hacker,\n";
-    s//_}->{_/e;print
+ m/a/and 1
+
+Instead you must write
+
+ m/a/ and 1
+
+with whitespace separating the operator from the closing delimiter of
+the regular expression.  Not having whitespace has resulted in a
+deprecation warning since Perl v5.14.0.
+
+=head2 qw(...) can no longer be used as parentheses
+
+C<qw> lists used to fool the parser into thinking they were always
+surrounded by parentheses.  This permitted some surprising constructions
+such as C<foreach $x qw(a b c) {...}>, which should really be written
+C<foreach $x (qw(a b c)) {...}>.  These would sometimes get the lexer into
+the wrong state, so they didn't fully work, and the similar C<foreach qw(a
+b c) {...}> that one might expect to be permitted never worked at all.
+
+This side effect of C<qw> has now been abolished.  It has been deprecated
+since Perl 5.13.11.  It is now necessary to use real parentheses
+everywhere that the grammar calls for them.
 
 =head2 Interaction of lexical and default warnings
 
@@ -404,14 +455,6 @@ C<our sub { ... }>.  These are now disallowed outside of the "lexical_subs"
 feature.  Under the "lexical_subs" feature they have new meanings described
 in L<perlsub/Lexical Subroutines>.
 
-=head2 C<gv_fetchmeth_*> and SUPER
-
-The various C<gv_fetchmeth_*> XS functions used to treat a package whose
-named ended with ::SUPER specially.  A method lookup on the Foo::SUPER
-package would be treated as a SUPER method lookup on the Foo package.  This
-is no longer the case.  To do a SUPER lookup, pass the Foo stash and the
-GV_SUPER flag.
-
 =head2 Defined values stored in environment are forced to byte strings
 
 A value stored in an environment variable has always been stringified.  In this
@@ -421,81 +464,19 @@ C<utf8::downgrade()> works, that result is used; otherwise, the equivalent of
 C<utf8::encode()> is used, and a warning is issued about wide characters
 (L</Diagnostics>).
 
-=head2 C<given> now aliases the global C<$_>
-
-Instead of assigning to an implicit lexical C<$_>, C<given> now makes the
-global C<$_> an alias for its argument, just like C<foreach>.  However, it
-still uses lexical C<$_> if there is lexical C<$_> in scope (again, just like
-C<foreach>) [perl #114020].
-
-=head2 qw(...) can no longer be used as parentheses
-
-C<qw> lists used to fool the parser into thinking they were always
-surrounded by parentheses.  This permitted some surprising constructions
-such as C<foreach $x qw(a b c) {...}>, which should really be written
-C<foreach $x (qw(a b c)) {...}>.  These would sometimes get the lexer into
-the wrong state, so they didn't fully work, and the similar C<foreach qw(a
-b c) {...}> that one might expect to be permitted never worked at all.
-
-This side effect of C<qw> has now been abolished.  It has been deprecated
-since Perl 5.13.11.  It is now necessary to use real parentheses
-everywhere that the grammar calls for them.
-
-=head2 C<\s> in regular expressions now matches a Vertical Tab
-
-[ XXX ]
-
-=head2 C</(?{})/> and C</(??{})/> have been heavily reworked
-
-The implementation of this feature has been almost completely rewritten.
-Although its main intent is to fix bugs, some behaviors, especially
-related to the scope of lexical variables, will have changed.  This is
-described more fully in the L</Selected Bug Fixes> section.
-
-=head2 C<\N{BELL}> now refers to U+1F514 instead of U+0007
-
-Unicode 6.0 reused the name "BELL" for a different code point than it
-traditionally had meant.  Since Perl v5.14, use of this name still
-referred to U+0007, but would raise a deprecation warning.  Now, "BELL"
-refers to U+1F514, and the name for U+0007 is "ALERT".  All the
-functions in L<charnames> have been correspondingly updated.
-
-=head2 Alphanumeric operators must now be separated from the closing
-delimiter of regular expressions
-
-You may no longer write something like:
-
- m/a/and 1
-
-Instead you must write
-
- m/a/ and 1
-
-with whitespace separating the operator from the closing delimiter of
-the regular expression.  Not having whitespace has resulted in a
-deprecation warning since Perl v5.14.0.
-
 =head2 C<require> dies for unreadable files
 
 When C<require> encounters an unreadable file, it now dies.  It used to
-ignore the file and continue searching the directories in @INC
+ignore the file and continue searching the directories in C<@INC>
 [perl #113422].
 
-=head2 Upgrade to the Unicode 6.2 beta
-
-Unicode 6.2 is proposing some changes that may very well break some CPAN
-modules.  The timing of this nicely coincides with Perl's being early in the
-release cycle.  This commit takes the current beta 6.2, adds the proposed
-changes that aren't yet in it, and subtracts the changes that would affect \X
-processing, as those turn out to have errors, and may have to be rethought.
-Unicode has been notified of these problems.
-
-This will allow us to gather data as to whether or not the proposed changes
-cause us problems.  These will be presented to Unicode to aid in their final
-decision as to whether or not to go forward with the changes.
+=head2 C<gv_fetchmeth_*> and SUPER
 
-These changes will be replaced by the final version of Unicode 6.2 before
-5.18.0 is released.
+The various C<gv_fetchmeth_*> XS functions used to treat a package whose
+named ended with ::SUPER specially.  A method lookup on the Foo::SUPER
+package would be treated as a SUPER method lookup on the Foo package.  This
+is no longer the case.  To do a SUPER lookup, pass the Foo stash and the
+GV_SUPER flag.
 
 =head1 Deprecations