5 perldelta - what is new for perl v5.13.1
9 This document describes differences between the 5.13.0 release and
12 If you are upgrading from an earlier release such as 5.10, first read
13 L<perl5120delta>, which describes differences between 5.10 and
16 =head1 Incompatible Changes
20 The backslash-c construct was designed as a way of specifying
21 non-printable characters, but there were no restrictions (on ASCII
22 platforms) on what the character following the C<c> could be. Now, that
23 character must be one of the ASCII characters.
25 =head2 localised tied hashes, arrays and scalars are no longed tied
32 # here, @a is a now a new, untied array
34 # here, @a refers again to the old, tied array
36 The new local array used to be made tied too, which was fairly pointless,
37 and has now been fixed. This fix could however potentially cause a change
38 in behaviour of some code.
40 =head2 C<given> return values
42 Starting from this release, C<given> blocks returns the last evaluated
43 expression, or an empty list if the block was exited by C<break>. Thus you
49 'integer' when /^[+-]?[0-9]+$/;
50 'float' when /^[+-]?[0-9]+(?:\.[0-9]+)?$/;
55 See L<perlsyn/Return value> for details.
57 =head1 Core Enhancements
59 =head2 Exception Handling Reliability
61 Several changes have been made to the way C<die>, C<warn>, and C<$@>
62 behave, in order to make them more reliable and consistent.
64 When an exception is thrown inside an C<eval>, the exception is no
65 longer at risk of being clobbered by code running during unwinding
66 (e.g., destructors). Previously, the exception was written into C<$@>
67 early in the throwing process, and would be overwritten if C<eval> was
68 used internally in the destructor for an object that had to be freed
69 while exiting from the outer C<eval>. Now the exception is written
70 into C<$@> last thing before exiting the outer C<eval>, so the code
71 running immediately thereafter can rely on the value in C<$@> correctly
72 corresponding to that C<eval>.
74 Likewise, a C<local $@> inside an C<eval> will no longer clobber any
75 exception thrown in its scope. Previously, the restoration of C<$@> upon
76 unwinding would overwrite any exception being thrown. Now the exception
77 gets to the C<eval> anyway. So C<local $@> is safe inside an C<eval>,
78 albeit of rather limited use.
80 Exceptions thrown from object destructors no longer modify the C<$@>
81 of the surrounding context. (If the surrounding context was exception
82 unwinding, this used to be another way to clobber the exception being
83 thrown. Due to the above change it no longer has that significance,
84 but there are other situations where C<$@> is significant.) Previously
85 such an exception was sometimes emitted as a warning, and then either
86 string-appended to the surrounding C<$@> or completely replaced the
87 surrounding C<$@>, depending on whether that exception and the surrounding
88 C<$@> were strings or objects. Now, an exception in this situation is
89 always emitted as a warning, leaving the surrounding C<$@> untouched.
90 In addition to object destructors, this also affects any function call
91 performed by XS code using the C<G_KEEPERR> flag.
93 C<$@> is also no longer used as an internal temporary variable when
94 preparing to C<die>. Previously it was internally necessary to put
95 any exception object (any non-string exception) into C<$@> first,
96 before it could be used as an exception. (The C API still offers the
97 old option, so an XS module might still clobber C<$@> in the old way.)
98 This change together with the foregoing means that, in various places,
99 C<$@> may be observed to contain its previously-assigned value, rather
100 than having been overwritten by recent exception-related activity.
102 Warnings for C<warn> can now be objects, in the same way as exceptions
103 for C<die>. If an object-based warning gets the default handling,
104 of writing to standard error, it will of course still be stringified
105 along the way. But a C<$SIG{__WARN__}> handler will now receive an
106 object-based warning as an object, where previously it was passed the
107 result of stringifying the object.
109 =head1 Modules and Pragmata
111 =head2 Updated Modules
117 The implementation of C<Errno> has been refactored to use about 55% less memory.
118 There should be no user-visible changes.
120 =item Perl 4 C<.pl> libraries
122 These historical libraries have been minimally modified to avoid using
123 C<$[>. This is to prepare them for the deprecation of C<$[>.
127 A bug has been fixed when deparsing a nextstate op that has both a
128 change of package (relative to the previous nextstate), or a change of
129 C<%^H> or other state, and a label. Previously the label was emitted
130 first, leading to syntactically invalid output because a label is not
131 permitted immediately before a package declaration, B<BEGIN> block,
132 or some other things. Now the label is emitted last.
136 =head2 Removed Modules and Pragmata
138 The following modules have been removed from the core distribution, and if
139 needed should be installed from CPAN instead.
145 =item C<Pod::Plainer>
151 The removal of C<Shell> has been deferred until after 5.14, as the
152 implementation of C<Shell> shipped with 5.12.0 did not correctly issue the
153 warning that it was to be removed from core.
155 =head1 New Documentation
161 L<perlgpl> has been updated to contain GPL version 1, as is included in the
162 F<README> distributed with perl.
166 =head1 Selected Bug Fixes
172 Naming a deprecated character in \N{...} will not leak memory.
176 FETCH is no longer called needlessly on some tied variables.
180 The trie runtime code should no longer allocate massive amounts of memory,
185 =head1 Changed Internals
191 The protocol for unwinding the C stack at the last stage of a C<die>
192 has changed how it identifies the target stack frame. This now uses
193 a separate variable C<PL_restartjmpenv>, where previously it relied on
194 the C<blk_eval.cur_top_env> pointer in the C<eval> context frame that
195 has nominally just been discarded. This change means that code running
196 during various stages of Perl-level unwinding no longer needs to take
197 care to avoid destroying the ghost frame.
201 The format of entries on the scope stack has been changed, resulting in a
202 reduction of memory usage of about 10%. In particular, the memory used by
203 the scope stack to record each active lexical variable has been halved.
207 Memory allocation for pointer tables has been changed. Previously
208 C<Perl_ptr_table_store> allocated memory from the same arena system as C<SV>
209 bodies and C<HE>s, with freed memory remaining bound to those arenas until
210 interpreter exit. Now it allocates memory from arenas private to the specific
211 pointer table, and that memory is returned to the system when
212 C<Perl_ptr_table_free> is called. Additionally, allocation and release are both
217 A new function, Perl_magic_methcall has been added that wraps the setup needed
218 to call a magic method like FETCH (the existing S_magic_methcall function has
219 been renamed S_magic_methcall1).
225 The following items are now deprecated.
229 =item C<Perl_ptr_table_clear>
231 C<Perl_ptr_table_clear> is no longer part of Perl's public API. Calling it now
232 generates a deprecation warning, and it will be removed in a future
237 =head1 Acknowledgements
239 Perl 5.13.1 represents thirty days of development since Perl 5.13.0 and
240 contains 15390 lines of changes across 289 files from 34 authors and
243 Thank you to the following for contributing to this release:
245 Ævar Arnfjörð Bjarmason, Arkturuz, Chris 'BinGOs' Williams, Craig A. Berry,
246 Curtis Jewell, Dan Dascalescu, David Golden, David Mitchell, Father
247 Chrysostomos, Gene Sullivan, gfx, Gisle Aas, H.Merijn Brand, James E Keenan,
248 James Mastros, Jan Dubois, Jesse Vincent, Karl Williamson, Leon Brocard,
249 Lubomir Rintel (GoodData), Nicholas Clark, Philippe Bruhat (BooK), Rafael
250 Garcia-Suarez, Rainer Tammer, Ricardo Signes, Richard Soderberg, Robin Barker,
251 Ruslan Zakirov, Steffen Mueller, Todd Rinaldo, Tony Cook, Vincent Pit, Zefram
253 =head1 Reporting Bugs
255 If you find what you think is a bug, you might check the articles
256 recently posted to the comp.lang.perl.misc newsgroup and the perl
257 bug database at http://rt.perl.org/perlbug/ . There may also be
258 information at http://www.perl.org/ , the Perl Home Page.
260 If you believe you have an unreported bug, please run the B<perlbug>
261 program included with your release. Be sure to trim your bug down
262 to a tiny but sufficient test case. Your bug report, along with the
263 output of C<perl -V>, will be sent off to perlbug@perl.org to be
264 analysed by the Perl porting team.
266 If the bug you are reporting has security implications, which make it
267 inappropriate to send to a publicly archived mailing list, then please send
268 it to perl5-security-report@perl.org. This points to a closed subscription
269 unarchived mailing list, which includes all the core committers, who be able
270 to help assess the impact of issues, figure out a resolution, and help
271 co-ordinate the release of patches to mitigate or fix the problem across all
272 platforms on which Perl is supported. Please only use this address for
273 security issues in the Perl core, not for modules independently
278 The F<Changes> file for an explanation of how to view exhaustive details
281 The F<INSTALL> file for how to build Perl.
283 The F<README> file for general stuff.
285 The F<Artistic> and F<Copying> files for copyright information.