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

[perl #121662] use a more stringent check for -DPERL_DISABLE_PMC

which Tom produced updated patch for, but then I grabbed the wrong
patch.

Make the test suite pass with -DPERL_DISABLE_PMC

Commit 9fdd5a7ac74817cfaab6 introduced new tests that fail when building
perl without PMC support.  In such cases, skip these new tests.

Avoid double quotes in switchM.t runperl args.

The new tests added in 9fdd5a7ac74817 were sending runperl a -e
command with double quotes around it, which confuses matters on
VMS where arguments get double quotes added unless they already
have them.  The solution is simple: just use the 'prog' parameter
to runperl and let runperl handle the quoting.

perldiag: Clarify non-char warning

What to do in this situation is currently subject to ticket
[perl #121226],  This more clearly documents what happens now.

[perl #121681] fix documentation of delete at the end of an array

Prepare Module::CoreList for 5.19.12 (not that it's expected to exist...)

Module-CoreList 3.10 released to CPAN

Add 5.19.11 epigraph

Bump version for 5.19.12 (not that it's expected to exist...)

Create new perldelta for 5.19.12 (not that it's expected to exist...)

Update Porting/Maintainers.pl - ExtUtils::Install was updated by 68659711db

Update perlhist

Finalize perldelta

Update Module::CoreList for 5.19.11

perldelta - Fill in the last remaining "todo"

Upgrade CPAN from version 2.05-TRIAL2 to 2.05

perldelta - Update, remove boilerplates, and do some copy-editing

Also update the template for utilities: a =head3 doesn't look right
directly under a =head1 so make it a =head2 instead.

Fill in perldelta for CPAN upgrade in commit 45a1388464

Also record that that commit actually upgraded CPAN to 2.05-TRIAL2, not
2.05-TRIAL.

perldelta for perlbug changes.

Update the other version number in ExtUtils::Install

perldelta for b51c3e77db (VMS glob changes).

ExtUtils-Install/t/Install.t: better -w tests

I recently added some tests to Install.t to check that files weren't
writeable. I used "-w $file", which gives a false positive if run as
root. So this commit changes the test to do a stat then test (mode & 0200);
hopefully that emulation on non-POSIX platforms is good enough for this to
be a valid test. perlport makes no mention of what stat->mode contains
on non-POSIX platforms.

(Chris fixed this this with 84d7dacc0cf1f by skipping the test if running
as root, but the current commit is more robust, in that is still tests for
correctness under root.)

perldelta - Consistent perl bug formatting

"[perl #1234]" is used as footnotes to text, but "perl #1234" reads better
in the body of the text.

perldelta - Mention a bug number

perldelta - Use canonical perl bug URL throughout for consistency

perldelta - Note a known problem with some MinGW builds on Windows

This came up on [perl #121643].

Skip writable tests in ExtUtils-Install when root

Bump ExtUtils::Install to 1.66

import experimental.pm

ExtUtils::Install was upgraded to 1.65 by 9345802d17

Upgrade Win32 from version 0.48 to 0.49

This fixes the build with gcc-4.8.1 from http://www.mingw.org and thus
resolves perl #121643.

perldelta for 78beb4ca6d

perldelta for e141190569

Remove unused variable

Fix DllMain definition to fix building with gcc-4.8.1 from mingw.org

This partly fixes perl #121643.

Set Off_t et al correctly for USE_LARGE_FILES builds on Windows

The canned config files used to build miniperl.exe (with some updates
applied by Makefile / makefile.mk) have the non-USE_LARGE_FILES settings
for Off_t, LSEEKSIZE and Off_t_size, resulting in an uninitialized memory
read in win32_fseek() in miniperl.exe, which recently started causing
exetype.pl to write a 4GB wperl.exe during the build of a 64-bit perl.

Change Makefile / makefile.mk to use the correct settings for the build of
miniperl.exe. This fixes perl #121471.

Bump ExtUtils::Install version to 1.65

Update perldelta for #121512 (9fdd5a7ac7)

perldelta: add entry for //m fix

run/locale.t: reindent block

Re-indent a block of code after the previous commit added an extra scope.
Whitespace-only change

run/locale.t: silence shell warnings

A couple of tests do

    local $ENV{LC_ALL} = "invalid";
    fresh_perl_is(...);

this causes a shell to be invoked with an invalid locale. Some shells
such as bash, become very noisy in this case:

    $ LC_ALL=invalid /bin/sh -c 'echo yes'
    /bin/sh: warning: setlocale: LC_ALL: cannot change locale (invalid): No such file or directory
    yes
    $

Silence these warnings by temporarily closing STDERR. Since the
fresh_perl_is() scripts themselves are run with STDERR set to /dev/null
anyway, this isn't a hardship.

perldelta updates

ExtUtils::Install handle symbolic and hard links

[perl #72028]

When upgrading an already-installed file, ExtUtils::Install could mess up
the permissions of files if the old versions of files were hard or
symbolic links. For example, if the Foo module had been installed as
lib/Foo.pm and for some reason (perhaps due to OS packaging) that file was
hard-linked to other/Foo.pm or replaced with a symbolic link to
other/Foo.pm, then when trying to install a newer release of Foo, the
permissions of the other/Foo.pm file could end up messed up.

This was due to ExtUtils::Install changing the permissions of the old file
before unlinking it; if the file was a link, then the linked file would
get the chmod instead. Since on POSIXy platforms it is the directory
permissions, not the file permissions, that affect whether a file can be
unlinked, the chmod was redundant anyway. So on these platforms, skip the
chmod.

I've also added tests for symlinked and hard-linked files.

[perl #120998] avoid caller() crashing on eval '' stack frames

Starting from v5.17.3-150-g19bcb54e caller() on an eval frame would
end up calling Perl_sv_grow() with newlen = 0xFFFFFFFF on 32-bit
systems.

This eventually started segfaulting with v5.19.0-442-gcbcb2a1 which
added code to round up allocations to the nearest 0x100, setting
newlen to 0, faulting when sv_setpvn() attempted to copy its source
string into the zero space provided.

PerlIO.pm: Make pod :utf8 caution more prominent

The :utf8 layer continues to have security issues.  This moves the
warning about that to earlier where it's more likely to be seen, and
makes it stand out more.

POSIX.pod: Nits

Most of the changes are to add C<> around code snippets, like function
macro and constant names.

There are a couple of grammar changes.

The only sort-of substantive change is that strtod() does respect
setlocale.  Previously it said it *should* respect setlocale.

PATCH: [perl #90646] perlop.pod: Clarify & | and ^ binary operations

initialise PL_watch_pvx

This global var is only used in debugging builds, but with
PERL_GLOBAL_STRUCT_PRIVATE builds, it gives valgrind errors. Just
initialise it to NULL.

I was originally trying to replicate smoke failures of
dist/Thread-Queue/t/07_lock.t under PERL_GLOBAL_STRUCT_PRIVATE, and
valgrind complained.

Attempt to satisfy CRLF expectations in perlbug on Windows.

Make perlbug encoding-agnostic in handling prepared reports.

Guessing the encoding of a report file prepared ahead of time is
really, well, too much guesswork, plus there are at least a couple
of mistakes in the implementation.  And we weren't even trying to
guess for reports created on-the-fly in an editor, which is a bit
inconsistent.

So handle prepared reports the same way as on-the-fly reports and
attachments, which means all I/O is done using the :raw layer.

This is only "Unicode-aware" in the sense that we're aware there
are a lot of encodings out there and we're trying not to mangle
them in transit by accidental conversion.  We're not doing any
explicit character set conversions and we shouldn't assert in the
MIME headers that we know what character set we're sending because
we don't.

Upgrade CPAN from 2.04-TRIAL to 2.05-TRIAL

-fwrapv is broken prior to gcc-4.3 (googled and patched by Zefram)

gcc 4.9 by default does some optimizations that break perl (#121505)

Patch by Tony Cook

PERL_GLOBAL_STRUCT threads issue

A test in op/threads.t roughly equivalent to this:

    use threads;
    sub f {};
    async \&f;

was randomly failing smokes under the combination of PERL_GLOBAL_STRUCT and
ASan.

This is due to the fact that, under PERL_GLOBAL_STRUCT, "global" vars
are actually allocated, and are freed as the very last thing before
exiting (later than perl_destruct()). In the code above, the created
thread is still exeecuting at this point, and so may access those "global"
vars.  ASan can detect that such a var is being accessed after being
freed; in this case due to PL_ppaddr being indexed in call_sv().

This is easily fixed using the PL_veto_cleanup mechanism; don't do those
final frees if there are still threads running.

perldelta updates

perldiag - Restore nitpick corrections

These were corrected in 4a70680af1 but then undone (presumably by
accident) in 727b63796f.

[perl #21442] on Win32, skip tests that won't work on FAT when on FAT

FAT doesn't support link() and its access time resolution is only to
the day.

[perl #21442] skip link() tests where the filesystem doesn't support them

[perl #21442] only check link() error codes where link() works

Skip the tests on non-NTFS.

[perl #21442] fix fs.t failures on Win32 FAT drive

See ticket for details. This commit does not fix all issues in #21442.

perldiag: Correct misstatement

It's not non-alphabetic characters that are discouraged; its the
characters X where \cX doesn't map to a control that are discouraged

tighten Storable's recognition of tied SVs

Since commit ff44333e5a9d9dca5272bb166df463607ebd3020, being RMAGICAL
and having tie magic is not sufficient to recognise an SV as tied.
When magic is turned off for mg_set(), the RMAGICAL flag is now left on,
so that vstrings will be recognised as such.  So Storable needs to check
whether the tie magic it sees is actually in effect, by also looking at
the GMAGICAL and SMAGICAL flags.

speed up miniperl require on Win32

These 3 optimizations reduce the number of, usually failing, I/O calls
for each "require" for miniperl only. None are appropriate except for
Win32. See #121119 for details.

nitpicks

Missed perldelta for 437e3a7 (for v5.19.8)