[perl #121676] Fix memory leak in backticks and system

Introduced by perl #113536. It doesn't actually leak on Windows XP due to
differences in the implementation of GetEnvironmentStringsW() compared to
later OSes, but the missing FreeEnvironmentStrings() was technically wrong
anyway, and does now bite. Thanks for Daniel Dragan for finding this.

use skip_all; test.pl plan does not support skip_all

Fix broken Makefile on Solaris 10.

This uses sed to avoid the problem of the sh not being modern enough.

The commiter moved the sed so it appears in just one place.

clarify SvPV documentation

perldelta: trim an absurd amount of trailing whitespace

perldelta: add obituary entry for Diana Rosa

[perl #121854] use re 'taint' regression

Commit v5.19.8-533-g63baef5 changed the handling of locale-dependent
regexes so that the pattern was considered tainted at compile-time, rather
than determining it each time at run-time whenever it executed a
locale-dependent node. Unfortunately due to the conflating of two flags,
RXf_TAINTED and RXf_TAINTED_SEEN, it had the side effect of permanently
marking a pattern as tainted once it had had a single tainted result.

E.g.

    use re qw(taint);
    use Scalar::Util qw(tainted);
    for ($^X, "abc") {
        /(.*)/ or die;
        print "not " unless tainted("$1"); print "tainted\n";
    };

which from 5.19.9 onwards output:

    tainted
    tainted

but with this commit (and with 5.19.8 and earlier), it now outputs:

    tainted
    not tainted

The RXf_TAINTED flag indicates that the pattern itself is tainted, e.g.

    $r = qr/$tainted_value/

while the RXf_TAINTED_SEEN flag means that the results of the last match
are tainted, e.g.

    use re 'tainted';
    $tainted =~ /(.*)/;
    # $1 is tainted

Pre 63baef5, the code used to look like:

    at run-time:

        turn off RXf_TAINTED_SEEN;
        while (nodes to execute) {
            switch(node) {
            case
                BOUNDL: /* and other locale-specific ops */
                    turn on RXf_TAINTED_SEEN;
                    ...;
            }
        }
        if (tainted || RXf_TAINTED)
            turn on RXf_TAINTED_SEEN;

63baef5 changed it to:

    at compile-time:

        if (pattern has locale ops)
            turn on RXf_TAINTED_SEEN;

    at run-time:

        while (nodes to execute) {
            ...
        }
        if (tainted || RXf_TAINTED)
            turn on RXf_TAINTED_SEEN;

This commit changes it to:

    at compile-time;

        if (pattern has locale ops)
            turn on RXf_TAINTED;

    at run-time:

        turn off RXf_TAINTED_SEEN;
        while (nodes to execute) {
            ...
        }
        if (tainted || RXf_TAINTED)
            turn on RXf_TAINTED_SEEN;

Correct v5.19.12-isms in Module-CoreList

bump the version to 5.20.0-RC0 to start on the road to release!

patchlevel: call it RC0 until RC1

there are no longer any problems in perldelta for now

replace 5.19.12 (never happening) with 5.20.0 in corelist

resort win32/pod.mak to please pod_rules.t

add known modules from perl520delta

regenerate META.json

perldelta: correct busted perldiag links

bump version to 5.20.0, install 5.20 perldelta

perlsub: Fix too-long verbatim line length

This was introduced by commit d3f8a934ef964c0f488e9c692275435d8ea2e291
which reverted earlier fixes, including this pod problem.

perlapi: Give more accurate value for needed free space

When converting to UTF-8, one usually doesn't need 14 bytes available
space, which is what previously was claimed  It acutally depends on the
value being converted.  This change gives the precise value.

ensure qw//, q'' and '' report line on a missing terminator

scan_str() only sets PL_multi_end on success, but the qw, q amd '' cases
were calling the COPLINE_SET_FROM_MULTI_END; macro before reporting
failure, overwriting the line used for reporting errors.

For the simplest case, as in the ticket and the tests, PL_multi_end is
zero, so the error is reported without a line number.

Revert "[perl #79908] Stop sub inlining from breaking closures"

This reverts commit 137da2b05b4b7628115049f343163bdaf2c30dbb. See the
"How about having a recommended way to add constant subs dynamically?"
thread on perl5-porters, specifically while it sucks that we have this
bug, it's been documented to work this way since 5.003 in "Constant
Functions" in perlsub:

    If the result after optimization and constant folding is either a
    constant or a lexically-scoped scalar which has no other references,
    then it will be used in place of function calls made without C<&>

    -- http://perldoc.perl.org/perlsub.html#Constant-Functions

Since we've had this documented bug for a long time we should introduce
this fix in a deprecation cycle rather than silently slowing down code
that assumes it's going to be optimized by constant folding.

I didn't revert the tests it t/op/sub.t, but turned them into TODO tests
instead.

Conflicts:
t/op/sub.t

perlsub: Improve the "Constant Functions" documentation

Ever since perl-5.003_95-19-g5431012 which incorporated this patch:

      Title:  "Improve and update documentation of constant subs"
       From:  Tom Phoenix <rootbeer@teleport.com>
     Msg-ID:  <Pine.GSO.3.96.970331122546.14185C-100000@kelly.teleport.com>
       Date:  Mon, 31 Mar 1997 13:05:54 -0800 (PST)
      Files:  pod/perlsub.pod

We've documented that "BEGIN { my $x = 1; *X = sub () { $x } }" creates
an inlined subroutine, we just weren't doing so very explicitly. Patch
the documentation so that we now have explicit examples for the behavior
mentioned in the first paragraph of the section.

This also adds an explicit mention of the behavior reported as a bug in
[RT #79908], shows the user that you can just use B::Deparse rather than
relying on a warning to see the effects of inlining, and replaces a
contrived way to avoid inlining with just adding a "return".

While writing these docs I found a bug in the warning behavior mentioned
here, which I filed as [RT #121841]

Merge branch 'perldelta' into blead

perldelta: mention the possible doom of EBCDIC

perldelta: standardize on Americanized spellings

one document, one standard

perldelta: crosslink to 5.18.0 delta for padrange

perldelta: nitpicks

List::Gather now has a patch upstream

perl5200delta: Correct which gcc versions we add -fwrapv for

perldelta: Data::Clone 0.004 works correctly on blead

[perl #121771] this new diagnostic was removed in 2e6f7c2a54

perldelta for 9625867354

remove a duplicate paragraph

merge paragraphs about Intel C++ Compiler

nitpicks

perldelta: correct Configure args for COW

perldelta: remove text duplicated mere lines above

perldelta: it will be perl520.dll, not perl519.dll

perldelta: better tense for mentioning an old version

perldelta: mark subroutine signatures as experimental

khw perl52000 changes

perldelta: remove some XXX todo text

perldelta: group regexp fixes

perldelta: group lexical subroutine fixes

perldelta: group debugger fixes

remove notice of changes entirely internal to 5.19.x

incorporate perl51911delta into perl5200delta

perldelta: edit up through but not including Selected Bug Fixes

first pass editing up through "Configuration and Compilation"

reorder "incompatible changes" section

reorder "core enhancements" section

incorporate perl51910delta into perl5200delta

incorporate perl5199delta into perl5200delta

incorporate perl5198delta into perl5200delta

incorporate perl5197delta into perl5200delta

incorporate perl5196delta into perl5200delta

incorporate perl5195delta into perl5200delta

incorporate perl5194delta into perl5200delta

incorporate perl5193delta into perl5200delta

incorporate perl5192delta into perl5200delta

incorporate perl5191delta into perl5200delta

incorporate perl5190delta into perl5200delta

sv.c: fix closing comment

replace /* with */

it didn't matter because it was immediately followed by another comment

document sv_gets() internals

sv_gets() contains some very dense code. while trying to rewrite I
learned a lot about it worked, and Nicholas asked me to update
the comments. So here they are. Hope this saves someone some heartache
trying to understand this code.

Implement "max waste" thresholds to avoid problems with COW and deliberately overallocated pvs

COW does not play nicely with "preallocate" algorithms.

More specifically code like sv_gets() wants to preallocate a large
buffer into $_ for performance reasons.

Prior to COW this was just fine. When someone assigned $_ to a
less volatile variable only the used portion of the buffer was copied,
and the extended buffer would be reused by sv_gets() and all was well.

With COW however this process is foiled. The preallocated buffer
get shared, and then when $_ is updated the buffer is dropped from $_,
leaving the other SV holding ownership of the overallocated buffer,
and causing sv_gets() to allocate a new buffer entirely. This process
would then repeat consuming time and lots of memory.

This patch introduces a "wastage" check to COW. When decided if we
should COW a string we look at the ratio and difference of SvCUR(sv)
and SvLEN(sv), which represent the "actual string length" and the
"allocated string length". When the difference exceeds a hard threshold,
or when the ration exceeds a designated factor then we do not COW.

This means that strings with large overallocations are not COWed.
Exactly how this works out in practice, where SvGROW() *always*
overallocates, is an open question.

See: https://rt.perl.org/Ticket/Display.html?id=121796

This patch also slightly tweaks SvGROW() not to do roundup on the first
allocation of the pv. Odds are good that the initial request realy does
want exactly what they expected. (SvGROW contrary to what the name
suggests is used for bother *extended* the size of a pv, and
initializing it the first time.)

[perl #121505] include -fwrapv by default for GCC 4.3 and later

perlre: Update obsolete example

/foo{4,3}/ now emits a message, contrary to what the pod claims.  Use a
different example that doesn't emit a message

Revert "Upgrade Devel::PPPort from 3.21 to 3.22"

This reverts commit 8e5dcc37de4ab79d8ec6f30798947ae97355ff2a, since
the SvREFCNT_dec_NN is bad (leaks).

Fix Encode 2.60 with g++

The recently added Encode 2.60 won't compile with g++, due to assigning
a const char * const pointer to a char* struct field.

The intent of the code itself is a bit unclear, but it appears to be
to set SvPVX as a read-only alias of a const string, using the SvLEN()=0
trick to avoid it being freed.

Fix the g++ builds by casting away the constness, and add some asserts and
comments to make it less unclear what's going on.

re-apply: Upgrade to Encode-2.60

Commit dc396cc293 was reverted by 547245703 due to issues under g++.
This commit re-applies the original commit; the next commit will fix those
issues.

-----

This upgrade includes the blead customizations from 080a704606 and
9e9002efd1 (amongst other changes) so that Perl 5.20.0 can ship with an
official CPAN release of Encode.

Fix remaining too-long verbatim lines in perlxstut.pod

Bring a few lines in perlxstut.pod under 80 cols

PATCH: [perl #121778]:BBC KAMIPO/autobox-String-Inflector

When I wrote commit 645de4ceb9a7cbcff21ef7df3a5f5eb36259571e,
and its predecessor commit, I wrongly thought that this code used a
count of bytes rather than characters.  I no longer remember why.
My previous experience was that a lot of code in the regex system talked
about characters in the documentation, when in fact bytes were what was
really meant.  The comments had never been properly updated to account
for UTF-8

But this code in fact is supposed to use a character count, and this
commit changes it to do so.

Revert "Upgrade to Encode-2.60"

This reverts commit dc396cc29397b262d3cc1473ade4229c84e82ca3.

[perl #121771] Revert the new warning for ++ on non- /\A[a-zA-Z]+[0-9]*\z/

This failed as in it was producing:

  Argument "123abc" treated as 0 in increment (++) at -e line 1.

when the user incremented that value (which is a lie).

This reverts commits 8140a7a801e37d147db0e5a8d89551d9d77666e0 and
2cd5095e471e1d84dc9e0b79900ebfd66aabc909.

I expect to revert this commit, and add fixes, after 5.20 is released.

Conflicts:
pod/perldiag.pod

Upgrade to Encode-2.60

This upgrade includes the blead customizations from 080a704606 and
9e9002efd1 (amongst other changes) so that Perl 5.20.0 can ship with an
official CPAN release of Encode.

Fix op/taint.t failure on Windows with 64-bit gcc-4.8.0 from MinGW-w64

MinGW-w64's 64-bit gcc now uses the SEH C++ exception model rather than
SJLJ or Dwarf2 (see http://mingw-w64.sourceforge.net/download.php).  For
such gccs, op/taint.t will need libgcc_s_seh-1.dll rather than
libgcc_s_sjlj-1.dll or libgcc_s_dw2-1.dll.  Fixes perl #121699.

Likewise, libwinpthread-1.dll is necessary if gcc was compiled with POSIX
threading and linked with the libwinpthread library, which is the case for
the gcc-4.8.2 toolchain that is likely to be used with the Strawberry Perl
5.20.x series.  Thanks to kmx for this.

Removed two other ghost modules from Module::CoreList

'XSLoader::XSLoader' and 'Pod::Functions::Functions'

Archaeology completed for OS2::* modules

perlpolicy: We generally deprecate for 2 major releases

Update perlpolicy to reflect the current policy,

Reinstate OS2::* modules to Module::CoreList

There is yet some archaeology to be done to find with which
releases the individual module versions increased.

Make corelist.pl find OS2 modules as well

Fix Windows build with MinGW-w64's gcc-4.8.0

The use of #defines like this:

#define ERROR_IPSEC_IKE_PROCESS_ERR_ID __MSABI_LONG(13834)
#define __MSABI_LONG(x)  x ## l

in new MinGW-w64 header files trips up Errno_pm.PL, causing hundreds of
warnings like this:

Bareword found where operator expected at (eval 22) line 1, near "13834l"
        (Missing operator before l?)

and hundreds of error values to go missing from Errno.pm.

This patch, from perl #121773, fixes that.

Special case PathTools in corelist.pl too

Remove PathTools::Cwd entries from Module::CoreList

vec(): downgrade before accessing string buffer

This code:

  #!perl -l
  $x = substr "\x{100}\xff\xfe", 1;
  print vec($x, 0, 8);
  print vec($x, 0, 8);

In 5.18 and earlier prints

  255
  255

With blead it prints:

  195
  255

This is due to the fact that it does SvPV() first to get the string buffer,
then calls sv_utf8_downgrade(). With COW, the PVX of the SV may no longer
equal the value earlier returned by SvPV(), but vec() continues to use the
old pointer. This bug has always been present, but COW made it more
noticeable.

The fix is to just redo the SvPV() after a downgrade.

Resolve [perl #121770] Win32 did indeed ship with v5.8.3

Resolve [perl #121769] with regards consistency of trailing zeroes.

Aliases were only being generated for perls >= 5.010, changed this
to >= 5.006

Found another place in corelist that required fixing for the doubling
problem.

Fix for Coverity perl5 CID 29034: Out-of-bounds read (OVERRUN) overrun-local: Overrunning array PL_reg_intflags name of 14 8-byte elements at element index 31 (byte offset 248) using index bit (which evaluates to 31).

Needed compile-time limits for the PL_reg_intflags_name so that the
bit loop doesn't waltz off past the array.  Could not use C_ARRAY_LENGTH
because the size of name array is not visible during compile time
(only const char*[] is), so modified regcomp.pl to generate the size,
made it visible only under DEBUGGING.  Did extflags analogously
even though its size currently exactly 32 already.  The sizeof(flags)*8
is extra paranoia for ILP64.

Fix for Coverity perl5 CID 29060: Pointer to local outside scope (RETURN_LOCAL) use_invalid: Using mode, which points to an out-of-scope variable tmode.

Duplicate the PerlIOBase_pushed call so that the tmode is in scope.

Fix for Coverity perl5 CID 29032: Out-of-bounds read (OVERRUN) overrun-local: Overrunning array anyofs of 34 8-byte elements at element index 34 (byte offset 272) using index index (which evaluates to 34).

Off-by-one error: because the test "index > number of elements"
should have used ">=", the anyofs[] could have been accessed one
past the end.  Use the C_ARRAY_LENGTH since we have it.
I think regprop is only used by -Mre=debug.

Update ExtUtils-MakeMaker to CPAN version 6.98

  [DELTA]

6.98 Tue Apr 29 21:27:59 BST 2014

    No changes from 6.97_02

6.97_02 Mon Apr 28 11:44:56 BST 2014
    Dist fixes:
    * Removed redundant File::Spec check from Makefile.PL

6.97_01 Thu Apr 24 14:23:02 BST 2014
    Bug fixes:
    * Resolve another regression related to not recursing into distdirs

6.96 Fri Apr 11 21:54:25 BST 2014

    No changes from 6.95_02

6.95_02 Mon Apr  7 15:26:20 BST 2014
    Bug fixes:
    * Work-around v5.10.1 for the MIN_PERL_VERSION v-string handling

6.95_01 Wed Apr  2 21:49:22 BST 2014
    Bug fixes:
    * Make MIN_PERL_VERSION handle v-strings properly

more Fix Windows build (of Encode) with VC++ 6.0

The previous commit (080a7046069084) broke g++ builds.
This commit, based on a suggestion by Jan, changes the test of whether
we're "in perl" from being the def'ness of U8 to being the def'ness of
H_Perl; and removes all the '#define U8 U8's that were formerly used to
signal this state.

Fix for Coverity perl5 CID 45366: Use after free (USE_AFTER_FREE) pass_freed_arg: Passing freed pointer save_input_locale as an argument to PerlIO_printf.

Printfing save-pvs after freeing them.

Fix Windows build (of Encode) with VC++ 6.0

Patch originally created by Daniel Dragan on perl #121554, and modified by
Dan Kogai to save introducing a warning on redefinition.

Sent upstream as cpan #95130.

Pseudo-fork dups arg array on argless calls

RT #121721.

A subroutine call like &foo; pushes a SUB context with the savearray field
unassigned, and with CxHASARGS() false. Most of the core knows not to use
this field without CxHASARGS() being true: except for Perl_cx_dup(),
which was still trying to dup it. This could lead to SEGVs on a fresh CX
stack, or possibly duping some other sub's @_ on a reused stack entry.

The fix is simple; don't dup this field unless CxHASARGS() is set.
Note that a similar test is already in place for the argarray field.

Fixed regressions in corelist with display of 0 ending perls

v5.x.10 perls were displaying twice in -a output

Both v5.x.0 and v5.x.10 perls were displaying twice in -v output

my_plvarsp nulling and PERL_GLOBAL_STRUCT_PRIVATE

With PERL_GLOBAL_STRUCT_PRIVATE, all "global" vars are in a malloc()d
structure pointed to by the static var my_plvarsp. At exit, this struct is
freed and my_plvarsp is set to NULL.

My previous commit c1181d2b skipped the free if PL_veto_cleanup is set
(as it would be if other threads are still running for example), but
still left my_plvarsp getting set to NULL. Thus other threads could still
deref a null pointer if they accessed a "global" var just as the main
thread was exiting.

This commit makes the veto skip the NULLing in addition to the freeing.

This commit is quite late into the code freeze, but it's a follow-up to the
earlier attempt to get smokes not to fail, and all the affected code is
within #ifdef PERL_GLOBAL_STRUCT_PRIVATE, so it shouldn't affect
mainstream builds at all. (Famous last words.)

perlapi: Clarify NUL handling for 2 fcns; nits

The string input to these two functions must be NUL terminated when the
length parameter is 0.

RMG - Note that the release announcement's web link will be in the email headers

Thanks to Smylers <Smylers@stripey.com> for this revelation!
http://nntp.perl.org/group/perl.perl5.porters/214662