[ this is a template for a new perldelta file. Any text flagged as XXX needs
to be processed before release. ]
-perldelta - what is new for perl v5.23.4
+perldelta - what is new for perl v5.23.6
=head1 DESCRIPTION
-This document describes differences between the 5.23.3 release and the 5.23.4
+This document describes differences between the 5.23.5 release and the 5.23.6
release.
-If you are upgrading from an earlier release such as 5.23.2, first read
-L<perl5233delta>, which describes differences between 5.23.2 and 5.23.3.
+If you are upgrading from an earlier release such as 5.23.4, first read
+L<perl5235delta>, which describes differences between 5.23.4 and 5.23.5.
=head1 Notice
=head1 Incompatible Changes
-=head2 Lexical $_ has been removed
+=head2 Some regular expression patterns that had runtime errors now
+don't compile at all
-C<my $_> was introduced in Perl v5.10, and subsequently caused much confusion
-with no obvious solution. In Perl v5.18.0, it was made experimental on the
-theory that it would either be removed or redesigned in a less confusing (but
-backward-incompatible) way. Over the following years, no alternatives were
-proposed. The feature has now been removed and will fail to compile.
+This should have been in the perldelta for 5.23.4, but was omitted.
-=head2 Only blanks and tabs are now allowed within C<[...]> within C<(?[...])>.
-
-The experimental Extended Bracketed Character Classes can contain
-regular bracketed character classes within them. These differ from
-regular ones in that white space is generally ignored, unless escaped by
-preceding it with a backslash. The white space that is ignored is now
-limited to just tab C<\t> and SPACE characters. Previously, it was any
-white space. See
-L<perlrecharclass/Extended Bracketed Character Classes>.
+Almost all Unicode properties using the C<\p{}> and C<\P{}> regular
+expression pattern constructs are now checked for validity at pattern
+compilation time, and invalid ones will cause the program to not
+compile. In earlier releases, this check was often deferred until run
+time. Whenever an error check is moved from run- to compile time,
+erroneous code is caught 100% of the time, whereas before it would only
+get caught if and when the offending portion actually gets executed,
+which for unreachable code might be never.
=head1 Deprecations
[ List each other deprecation as a =head2 entry ]
+=head2 Using code points above the platform's C<IV_MAX> is now
+deprecated
+
+Unicode defines code points in the range C<0..0x10FFFF>. Some standards
+at one time defined them up to 2**31 - 1, but Perl has allowed them to
+be as high as anything that will fit in a word on the platform being
+used. However, use of those above the platform's C<IV_MAX> is broken in
+some constructs, notably C<tr///>, regular expression patterns involving
+quantifiers, and in some arithmetic and comparison operations, such as
+being the upper limit of a loop. Now the use of such code points raises
+a deprecation warning, unless that warning category is turned off.
+C<IV_MAX> is typically 2**31 -1 on 32-bit platforms, and 2**63-1 on
+64-bit ones.
+
+=head2 Doing bitwise operations on strings containing code points above
+0xFF is deprecated
+
+The string bitwise operators treat their operands as strings of bytes,
+and values beyond 0xFF are nonsensical in this context. To operate on
+encoded bytes, first encode the strings. To operate on code points'
+numeric values, use C<split> and C<map ord>. In the future, this
+warning will be replaced by an exception.
+
=head1 Performance Enhancements
XXX Changes which enhance performance without changing behaviour go here.
=item *
-L<XXX> has been upgraded from version A.xx to B.yy.
+L<Data::Dumper> has been upgraded from version 2.158 to 2.159.
+
+This adds a "Trailingcomma" option, which when enabled adds a trailing comma
+after the last element of dumped arrays and hashes that would otherwise be
+followed immediately by a line break. [perl #126813]
+
+=item *
+
+L<DynaLoader> has been upgraded from version 1.36 to 1.37.
+
+Fixed an else nesting issue in dynamic loading support for OS/390 (and
+similar systems) that was introduced in 1.36.
+
+=item *
+
+L<utf8> has been upgraded from 1.17 to 1.18.
+
+Partly reverted a micro-optimization to F<lib/utf_heavy.pl> that
+caused self-recursion when it was loaded with C<${^ENCODING}> set.
+[perl #126593]
+
+=item *
+
+The modules L<sigtrap>, L<DB>, and the perl debugger could have under
+rare circumstances, without you expecting it, output containing raw
+control characters. This has been fixed.
=back
=item *
-L<Character following \p must be '{' or a single-character Unicode property name in regex;|perldiag/"Character following \%c must be '{' or a single-character Unicode property name in regex; marked by <-- HERE in m/%s/">
+L<message|perldiag/"Invalid number '%s' for -C option.">
-=item *
+(F) You supplied a number to the -C option that either has extra leading
+zeroes or overflows perl's unsigned integer representation.
-L<perldiag/"Illegal user-defined property name">
=back
=item *
-L<"Can't modify non-lvalue subroutine call of &%s"|perldiag/"Can't modify non-lvalue subroutine call of &%s">
-
-This error now reports the name of the non-lvalue subroutine you
-attempted to use as an lvalue.
+XXX Describe change here
=back
=item *
-Using the C<NO_HASH_SEED> define in combination with the default hash algorithm
-C<PERL_HASH_FUNC_ONE_AT_A_TIME_HARD> resulted in a fatal error while compiling
-the interpreter, since 5.17.10. This has been fixed.
+XXX
=back
=item *
-XXX
+F<make_ext.pl> is no longer inappropriately silent. This was caused
+by an operator precedence error introduced in 5.23.4.
=back
[ Within the sections, list each platform as a =item entry with specific
changes as paragraphs below it. ]
+=over 4
+
+=item All Solaris now builds shared libperl
+
+Solaris and variants like OpenIndiana now always build with the shared
+Perl library (Configure -Duseshrplib). This was required for the
+OpenIndiana builds, but this has also been the setting for Oracle/Sun
+Perl builds for several years.
+
+=back
+
=head2 New Platforms
XXX List any platforms that this version of perl compiles on, that previous
=over 4
-=item XXX-some-platform
+=item OpenIndiana
-XXX
+OpenIndiana (continuation of OpenSolaris) builds were not working due
+to problems with the Perl shared library. This should be working now.
+L<[perl #126958]|https://rt.perl.org/Ticket/Display.html?id=126958>
=back
=over 4
-=item XXX-some-platform
-
-XXX
-
-=item Win32
+=item EBCDIC platforms, such as z/OS
-=over
+UTF-EBCDIC is like UTF-8, but for EBCDIC platforms. It now has been
+extended so that it can represent code points up to 2 ** 64 - 1 on
+platforms with 64-bit words. This brings it into parity with UTF-8.
+This enhancement requires an incompatible change to the representation
+of code points in the range 2 ** 30 to 2 ** 31 -1 (the latter was the
+previous maximum representable code point). This means that a file that
+contains one of these code points, written out with previous versions of
+perl cannot be read in, without conversion, by a perl containing this
+change. We do not believe any such files are in existence, but if you
+do have one, submit a ticket at L<mailto:perlbug@perl.org>, and we will
+write a conversion script for you.
-=item *
+=item OS X/Darwin
-A new build option C<USE_NO_REGISTRY> has been added to the makefiles. This
-option is off by default, meaning the default is to do Windows registry lookups.
-This option stops Perl from looking inside the registry for anything. For what
-values are looked up in the registry see L<perlwin32>. Internally, in C, the
-name of this option is C<WIN32_NO_REGISTRY>.
+Builds with both -DDEBUGGING and threading enabled would fail with a
+"panic: free from wrong pool" error when built or tested from Terminal
+on OS X. This was caused by perl's internal management of the
+environment conflicting with an atfork handler using the libc
+setenv() function to update the environment.
-=item *
+Perl now uses setenv()/unsetenv() to update the environment on OS X.
+[perl #126240]
-The behavior of Perl using C<HKEY_CURRENT_USER\Software\Perl> and
-C<HKEY_LOCAL_MACHINE\Software\Perl> to lookup certain values, including
-C<%ENV> vars starting with C<PERL> has changed. Previously, the 2 keys were
-checked for entries at all times through Perl processes life time even if they
-did not exist. For performance reasons, now, if the root key (i.e.
-C<HKEY_CURRENT_USER\Software\Perl> or C<HKEY_LOCAL_MACHINE\Software\Perl>) does
-not exist at process start time, it will not be checked again for C<%ENV>
-override entries for the remainder of the Perl processes life. This more
-closely matches Unix behaviour in that the enviroment is copied or inherited on
-startup and changing the variable in the parent process or another process or
-editing <.bashrc> will not change the enviromental variable in other existing,
-running, processes.
+=item ppc64el floating point
-=back
+The floating point format of ppc64el (Debian naming for little-endian
+PowerPC) is now detected correctly.
=back
=item *
-L<perlapi/sv_backoff> had its return type changed fron C<int> to C<void>. It
-previously has always returned C<0> since 5.000 stable but that was
-undocumented. Although C<sv_backoff> is marked as public API, XS code is not
-expected to be impacted since the proper API call would be through public API
-C<sv_setsv(sv, &PL_sv_undef)>, or quasi-public C<SvOOK_off>, or non-public
-C<SvOK_off> calls, and the return value of C<sv_backoff> was previously a
-meaningless constant that can be rewritten as C<(sv_backoff(sv),0)>.
-
-=item *
-
-The C<EXTEND> and C<MEXTEND> macros have been improved to avoid various
-issues with integer truncation and wrapping. In particular, some casts
-formerly used within the macros have been removed. This means for example
-that passing an unsigned nitems arg is likely to raise a compiler warning
-now (it's always been documented to require a signed value; formerly int,
-lately SSize_t).
-
-=item *
-
-(This was actually done in v5.23.2, but the perldelta entry got missed.)
-The way that C<OP_AASSIGN> handles assignment with potentially common
-values (e.g. C<($a,$b) = ($b, $a)> has changed. In particular the
-C<OPpASSIGN_COMMON> flag has been replaced with three more specific flags:
-
- OPpASSIGN_COMMON_AGG
- OPpASSIGN_COMMON_RC1
- OPpASSIGN_COMMON_SCALAR
-
-and the runtime now sometimes does a mark and sweep using the C<SVf_BREAK>
-to detect common elements.
+Perl core code and the threads extension have been annotated so that
+if Perl is configured to use threads, during compile-time clang (3.6
+or later) will warn about suspicious uses of mutexes.
+See L<http://clang.llvm.org/docs/ThreadSafetyAnalysis.html> for more
+information.
=back
=item *
-There were places in regular expression patterns where comments
-(C<(?#...)>) weren't allowed, but should have been. This is now fixed.
-[perl #116639]
+C</...\G/> no longer crashes on utf8 strings. When C<\G> is a fixed number
+of characters from the start of the regex, perl needs to count back that
+many characters from the current C<pos()> position and start matching from
+there. However, it was counting back bytes rather than characters, which
+could lead to panics on utf8 strings.
=item *
-A regression from perl v5.20 has been fixed, in which some syntax errors
-in L<C<(?[...])>|perlrecharclass/Extended Bracketed Character Classes>
-constructs within regular expression patterns could cause a segfault
-instead of a proper error message. [perl #126180]
+In some cases operators that return integers would return negative
+integers as large positive integers. [perl #126635]
=item *
-Some problems with attempting to extend the perl stack to around 2G or 4G
-entries have been fixed. This was particularly an issue on 32-bit perls
-built to use 64-bit integers, and was easily noticeable with the list
-repetition operator, e.g.
+The pipe() operator would assert for DEBUGGING builds instead of
+producing the correct error message. The condition asserted on is
+detected and reported on correctly without the assertions, so the
+assertions were removed. [perl #126480]
+
+=item *
- @a = (1) x $big_number
+In some cases, failing to parse a here-doc would attempt to use freed
+memory. This was caused by a pointer not being restored correctly.
+[perl #126443]
+
+=item *
-Formerly perl may have crashed, depending on the exact value of
-$big_number; now it will typically raise an exception.
-[perl #125937]
+C<< @x = sort { *a = 0; $a <=> $b } 0 .. 1 >> no longer frees the GP
+for *a before restoring its SV slot. [perl #124097]
=back
XXX Generate this with:
- perl Porting/acknowledgements.pl v5.23.3..HEAD
+ perl Porting/acknowledgements.pl v5.23.5..HEAD
=head1 Reporting Bugs