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

[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