In perl.git, the branch blead has been updated

<http://perl5.git.perl.org/perl.git/commitdiff/31b19988e6480269b055fedaa6bd747cdf16ac19?hp=4368ade6e8b90e883c9c9a6d3c3484da376607a6>

- Log -----------------------------------------------------------------
commit 31b19988e6480269b055fedaa6bd747cdf16ac19
Author: Karl Williamson <[email protected]>
Date:   Mon Apr 18 18:06:52 2016 -0600

    perldelta: Remove error/warning explanations
    
    Only the text of these should be present in a delta, with a link to the
    full explanation.  Most of perldelta conformed to this, but not all.

M       pod/perldelta.pod

commit e40834e7ab0fcda3bbb89885880512dc96ca4c9a
Author: Karl Williamson <[email protected]>
Date:   Mon Apr 18 18:06:31 2016 -0600

    perldelta: Add some C<>

M       pod/perldelta.pod

commit 76975f247d006023d00bf7bc7f10030121b7b71c
Author: Karl Williamson <[email protected]>
Date:   Mon Apr 18 18:04:03 2016 -0600

    perldelta: Clarifications, corrections, wordsmithing
    
    I also removed one instance of a 5.23-only bug, which isn't relevant to
    a dot zero delta

M       pod/perldelta.pod
-----------------------------------------------------------------------

Summary of changes:
 pod/perldelta.pod | 130 ++++++++++++++++++++----------------------------------
 1 file changed, 48 insertions(+), 82 deletions(-)

diff --git a/pod/perldelta.pod b/pod/perldelta.pod
index 85c7536..16c7e89 100644
--- a/pod/perldelta.pod
+++ b/pod/perldelta.pod
@@ -69,8 +69,8 @@ to do.  For example, for the overshift a common C behavior is
   # And the same for <<, while Perl now produces 0 for both.
 
 Now these behaviors are well-defined under Perl, regardless of what
-the underlying C implementation does.  Note, however, that you cannot
-escape the native integer width, you need to know how far left you
+the underlying C implementation does.  Note, however, that you are still
+constrained by the native integer width: you need to know how far left you
 can go.  You can use for example:
 
   use Config;
@@ -104,7 +104,7 @@ if "perl" is followed by "6".
 =head2 Set proper umask before calling C<mkstemp(3)>
 
 In 5.22 perl started setting umask to 0600 before calling C<mkstemp(3)>
-and restoring it afterwards. This wrongfully tells open(2) to strip
+and restoring it afterwards. This wrongfully tells C<open(2)> to strip
 the owner read and write bits from the given mode before applying it,
 rather than the intended negation of leaving only those bits in place.
 
@@ -138,7 +138,7 @@ while a typical C<getenv()> would return the first entry. 
We now
 make sure C<%ENV> contains the same as what C<getenv> returns.
 
 Second, we remove duplicates from C<environ[]>, so if a setting
-with that name is set in C<%ENV> we won't pass an unsafe value
+with that name is set in C<%ENV>, we won't pass an unsafe value
 to a child process.
 
 [CVE-2016-2381]
@@ -274,18 +274,18 @@ 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.
 
-=head2 sysread(), syswrite(), recv() and send() are deprecated on
+=head2 C<sysread()>, C<syswrite()>, C<recv()> and C<send()> are deprecated on
 :utf8 handles
 
-The sysread(), recv(), syswrite() and send() operators
+The C<sysread()>, C<recv()>, C<syswrite()> and C<send()> operators
 are deprecated on handles that have the C<:utf8> layer, either
 explicitly, or implicitly, eg., with the C<:encoding(UTF-16LE)> layer.
 
-Both sysread() and recv() currently use only the C<:utf8> flag for the
-stream, ignoring the actual layers.  Since sysread() and recv() do no
+Both C<sysread()> and C<recv()> currently use only the C<:utf8> flag for the
+stream, ignoring the actual layers.  Since C<sysread()> and C<recv()> do no
 UTF-8 validation they can end up creating invalidly encoded scalars.
 
-Similarly, syswrite() and send() use only the C<:utf8> flag, otherwise
+Similarly, C<syswrite()> and C<send()> use only the C<:utf8> flag, otherwise
 ignoring any layers.  If the flag is set, both write the value UTF-8
 encoded, even if the layer is some different encoding, such as the
 example above.
@@ -293,7 +293,7 @@ example above.
 Ideally, all of these operators would completely ignore the C<:utf8>
 state, working only with bytes, but this would result in silently
 breaking existing code.  To avoid this a future version of perl will
-throw an exception when any of sysread(), recv(), syswrite() or send()
+throw an exception when any of C<sysread()>, C<recv()>, C<syswrite()> or 
C<send()>
 are called on handle with the C<:utf8> layer.
 
 =head1 Performance Enhancements
@@ -321,14 +321,14 @@ caseless one.
 
 C</fixed-substr/> has been made much faster.
 
-On platforms with a libc memchr() implementation which makes good use of
+On platforms with a libc C<memchr()> implementation which makes good use of
 underlying hardware support, patterns which include fixed substrings will now
 often be much faster; for example with glibc on a recent x86_64 CPU, this:
 
     $s = "a" x 1000 . "wxyz";
     $s =~ /wxyz/ for 1..30000
 
-is now about 7 times faster.  On systems with slow memchr(), e.g. 32-bit ARM
+is now about 7 times faster.  On systems with slow C<memchr()>, e.g. 32-bit ARM
 Raspberry Pi, there will be a small or little speedup.  Conversely, some
 pathological cases, such as C<"ab" x 1000 =~ /aa/> will be slower now; up to 3
 times slower on the rPi, 1.5x slower on x86_64.
@@ -355,9 +355,9 @@ Creating Perl debugger data structures (see 
L<perldebguts/"Debugger Internals">)
 for XSUBs and const subs has been removed.  This removed one glob/scalar combo
 for each unique C<.c> file that XSUBs and const subs came from.  On startup
 (C<perl -e"0">) about half a dozen glob/scalar debugger combos were created.
-Loading XS modules created more glob/scalar combos.  These things were created
-regardless of whether the perl debugger was being used or not, unlike for pure
-perl subs, and ignores that the perl debugger can not debug C code.
+Loading XS modules created more glob/scalar combos.  These things were
+being created regardless of whether the perl debugger was being used,
+and despite the fact that it can't debug C code anyway
 
 =item *
 
@@ -822,7 +822,7 @@ A number of cleanups have been made to perlcall, including:
 
 =item *
 
-use EXTEND(SP, n) and PUSHs() instead of XPUSHs() where applicable
+use C<EXTEND(SP, n)> and C<PUSHs()> instead of C<XPUSHs()> where applicable
 and update prose to match
 
 =item *
@@ -984,7 +984,7 @@ The usage of C<FIRSTKEY> and C<NEXTKEY> has been clarified.
 
 =item *
 
-Discourage use of 'In' prefix for Unicode Block property.
+Discourage use of 'In' as a prefix signifying the Unicode Block property.
 
 =back
 
@@ -1036,11 +1036,6 @@ diagnostic messages, see L<perldiag>.
 
 L<%s must not be a named sequence in transliteration operator|perldiag/"%s 
must not be a named sequence in transliteration operator">
 
-(F) Transliteration (C<tr///> and C<y///>) transliterates individual
-characters.  But a named sequence by definition is more than an
-individual character, and hence doing this operation on it doesn't make
-sense.
-
 =item *
 
 L<Can't find Unicode property definition "%s" in regex;|perldiag/"Can't find 
Unicode property definition "%s" in regex; marked by <-- HERE in m/%s/">
@@ -1049,9 +1044,6 @@ L<Can't find Unicode property definition "%s" in 
regex;|perldiag/"Can't find Uni
 
 L<Can't redeclare "%s" in "%s"|perldiag/"Can't redeclare "%s" in "%s"">
 
-(F) A "my", "our" or "state" declaration was found within another declaration,
-such as C<my ($x, my($y), $z)> or C<our (my $x)>.
-
 =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 b ... [21 chars 
truncated]
@@ -1069,9 +1061,6 @@ L<Illegal user-defined property name|perldiag/"Illegal 
user-defined property nam
 
 L<Invalid number '%s' for -C option.|perldiag/"Invalid number '%s' for -C 
option.">
 
-(F) You supplied a number to the -C option that either has extra leading
-zeroes or overflows perl's unsigned integer representation.
-
 =item *
 
 L<<< Sequence (?... not terminated in regex; marked by S<<-- HERE> in 
mE<sol>%sE<sol>|perldiag/"Sequence (?... not terminated in regex; marked by <-- 
HERE in mE<sol>%sE<sol>" >>>
@@ -1101,25 +1090,6 @@ perldiag/Assuming NOT a POSIX class since %s in regex; 
marked by <-- HERE in mE<
 
 L<%s() is deprecated on :utf8 handles|perldiag/"%s() is deprecated on :utf8 
handles">
 
-(W deprecated) The sysread(), recv(), syswrite() and send() operators
-are deprecated on handles that have the C<:utf8> layer, either
-explicitly, or implicitly, eg., with the C<:encoding(UTF-16LE)> layer.
-
-Both sysread() and recv() currently use only the C<:utf8> flag for the
-stream, ignoring the actual layers.  Since sysread() and recv() do no
-UTF-8 validation they can end up creating invalidly encoded scalars.
-
-Similarly, syswrite() and send() use only the C<:utf8> flag, otherwise
-ignoring any layers.  If the flag is set, both write the value UTF-8
-encoded, even if the layer is some different encoding, such as the
-example above.
-
-Ideally, all of these operators would completely ignore the C<:utf8>
-state, working only with bytes, but this would result in silently
-breaking existing code.  To avoid this a future version of perl will
-throw an exception when any of sysread(), recv(), syswrite() or send()
-are called on handle with the C<:utf8> layer.
-
 =back
 
 =head2 Changes to Existing Diagnostics
@@ -1320,7 +1290,7 @@ L<[perl 
#126847]|https://rt.perl.org/Ticket/Display.html?id=126847>
 
 =item *
 
-Under some circumstances IRIX stdio fgetc() and fread() set the errno to
+Under some circumstances IRIX stdio C<fgetc()> and C<fread()> set the errno to
 C<ENOENT>, which made no sense according to either IRIX or POSIX docs.  Errno
 is now cleared in such cases.
 L<[perl #123977]|https://rt.perl.org/Ticket/Display.html?id=123977>
@@ -1357,9 +1327,9 @@ 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.
+C<setenv()> function to update the environment.
 
-Perl now uses setenv()/unsetenv() to update the environment on OS X.
+Perl now uses C<setenv()>/C<unsetenv()> to update the environment on OS X.
 L<[perl #126240]|https://rt.perl.org/Ticket/Display.html?id=126240>
 
 =back
@@ -1370,7 +1340,7 @@ L<[perl 
#126240]|https://rt.perl.org/Ticket/Display.html?id=126240>
 
 =item *
 
-All Solaris now builds shared libperl.
+All Solaris variants now build a shared libperl
 
 Solaris and variants like OpenIndiana now always build with the shared
 Perl library (Configure -Duseshrplib).  This was required for the
@@ -1456,11 +1426,12 @@ C, the name of this option is C<WIN32_NO_REGISTRY>.
 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
+for entries at all times through the perl process's 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
+override entries for the remainder of the perl process's life.  This more
 closely matches Unix behavior in that the environment is copied or inherited
 on startup and changing the variable in the parent process or another process
 or editing F<.bashrc> will not change the environmental variable in other
@@ -1661,7 +1632,8 @@ L<[perl 
#121351]|https://rt.perl.org/Ticket/Display.html?id=121351>
 
 =item *
 
-Remove unwarranted assertion in C<Perl_newATTRSUB_x()>. If a stub subroutine
+An unwarranted assertion in C<Perl_newATTRSUB_x()> has been removed.  If
+a stub subroutine
 definition with a prototype has been seen, then any subsequent stub (or
 definition) of the same subroutine with an attribute was causing an assertion
 failure because of a null pointer.
@@ -1669,7 +1641,7 @@ L<[perl 
#126845]|https://rt.perl.org/Ticket/Display.html?id=126845>
 
 =item *
 
-Replace C<::> with C<__> in C<ExtUtils::ParseXS> like it's done for
+C<::> has been replaced by C<__> in C<ExtUtils::ParseXS>, like it's done for
 parameters/return values. This is more consistent, and simplifies writing XS
 code wrapping C++ classes into a nested Perl namespace (it requires only
 a typedef for C<Foo__Bar> rather than two, one for C<Foo_Bar> and the other
@@ -1677,8 +1649,9 @@ for C<Foo::Bar>).
 
 =item *
 
-Deprecate the C<to_utf8_case()> function, see
-L<http://nntp.perl.org/group/perl.perl5.porters/233287>.
+The C<to_utf8_case()> function is now deprecated.  Instead use
+C<toUPPER_utf8>, C<toTITLE_utf8>, C<toLOWER_utf8>, and C<toFOLD_utf8>.
+(See L<http://nntp.perl.org/group/perl.perl5.porters/233287>.)
 
 =item *
 
@@ -1693,15 +1666,11 @@ information.
 The C<signbit()> emulation has been enhanced.  This will help older
 and/or more exotic platforms or configurations.
 
-=item *
-
-The C<to_utf8_case> function is discouraged in favor of C<toUPPER_utf8>,
-C<toTITLE_utf8>, C<toLOWER_utf8>, and C<toFOLD_utf8>.
 
 =item *
 
-EBCDIC code paths have largely been unified with non-EBCDIC ones to
-avoid repetition and make maintenance easier.
+Most EBCDIC-specific code in the core has been unified with non-EBCDIC
+code, to avoid repetition and make maintenance easier.
 
 =item *
 
@@ -1727,8 +1696,9 @@ meaningless constant that can be rewritten as 
C<(sv_backoff(sv),0)>.
 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 argument is likely to raise a compiler warning now (it's always
-been documented to require a signed value; formerly int, lately SSize_t).
+unsigned C<nitems> argument is likely to raise a compiler warning now
+(it's always been documented to require a signed value; formerly int,
+lately SSize_t).
 
 =item *
 
@@ -1755,7 +1725,7 @@ I<IsMyProperty> not defined at the time of the pattern 
compilation.
 
 =item *
 
-Perl's memcpy(), memmove(), memset() and memcmp() fallbacks are now
+Perl's C<memcpy()>, C<memmove()>, C<memset()> and C<memcmp()> fallbacks are now
 more compatible with the originals.  [perl #127619]
 
 =item *
@@ -1765,13 +1735,9 @@ to modify the source SV, resulting in the program dying. 
[perl #127635]
 
 =item *
 
-Fixed a spurious warning about posix character classes. [perl #127581]
-
-=item *
-
-Fixed an obscure case where a pattern could fail to match. This only 
-occurred when matching characters from the set of C1 controls, when
-the target matched string was in UTF-8, and only on EBCDIC platforms.
+Fixed an EBCDIC-platform-only case where a pattern could fail to match. This
+occurred when matching characters from the set of C1 controls when the
+target matched string was in UTF-8.
 
 =item *
 
@@ -1779,7 +1745,7 @@ Narrow the filename check in F<strict.pm> and 
F<warnings.pm>. Previously,
 it assumed that if the filename (without the F<.pmc?> extension) differed
 from the package name, if was a misspelled use statement (i.e. C<use Strict>
 instead of C<use strict>). We now check whether there's really a 
-miscapitalization happening, and not another issue.
+miscapitalization happening, and not some other issue.
 
 =item *
 
@@ -1795,7 +1761,7 @@ unterminated character classes while there are trailing 
backslashes.
 =item *
 
 Line numbers larger than 2**31-1 but less than 2**32 are no longer
-returned by caller() as negative numbers.  [perl #126991]
+returned by C<caller()> as negative numbers.  [perl #126991]
 
 =item *
 
@@ -1820,7 +1786,7 @@ complains about the unterminated here-doc.  [perl #125540]
 
 =item *
 
-untie() would sometimes return the last value returned by the UNTIE()
+C<untie()> would sometimes return the last value returned by the C<UNTIE()>
 handler as well as it's normal value, messing up the stack.  [perl
 #126621]
 
@@ -1832,8 +1798,8 @@ Fixed an operator precedence problem when C< castflags & 
2> is true.
 =item *
 
 Caching of DESTROY methods could result in a non-pointer or a
-non-STASH stored in the SvSTASH() slot of a stash, breaking the B
-STASH() method.  The DESTROY method is now cached in the MRO metadata
+non-STASH stored in the C<SvSTASH()> slot of a stash, breaking the B
+C<STASH()> method.  The DESTROY method is now cached in the MRO metadata
 for the stash.  [perl #126410]
 
 =item *
@@ -1953,7 +1919,7 @@ L<[perl 
#126822]|https://rt.perl.org/Ticket/Display.html?id=126822>
 
 =item *
 
-Calling mg_set() in leave_scope() no longer leaks.
+Calling C<mg_set()> in C<leave_scope()> no longer leaks.
 
 =item *
 
@@ -1978,7 +1944,7 @@ instead of the proper error message.  This has now been 
fixed. [perl
 
 =item *
 
-An earlier commit added a message when a quantifier in a regular
+Perl 5.20 added a message when a quantifier in a regular
 expression was useless, but then caused the parser to skip it;
 this caused the surplus quantifier to be silently ignored, instead
 of throwing an error. This is now fixed. [perl #126253]
@@ -2055,7 +2021,7 @@ L<[perl 
#126186]|https://rt.perl.org/Ticket/Display.html?id=126186>
 
 =item *
 
-Several bugs, including a segmentation fault, have been fixed with the bounds
+Several bugs, including a segmentation fault, have been fixed with the boundary
 checking constructs (introduced in Perl 5.22) C<\b{gcb}>, C<\b{sb}>, C<\b{wb}>,
 C<\B{gcb}>, C<\B{sb}>, and C<\B{wb}>.  All the C<\B{}> ones now match an empty
 string; none of the C<\b{}> ones do.
@@ -2086,7 +2052,7 @@ The PadlistNAMES macro is an lvalue again.
 
 Zero -DPERL_TRACE_OPS memory for sub-threads.
 
-perl_clone_using() was missing Zero init of PL_op_exec_cnt[].  This
+C<perl_clone_using()> was missing Zero init of PL_op_exec_cnt[].  This
 caused sub-threads in threaded -DPERL_TRACE_OPS builds to spew exceedingly
 large op-counts at destruct.  These counts would print %x as "ABABABAB",
 clearly a mem-poison value.

--
Perl5 Master Repository

Reply via email to