Updated ACKNOWLEDGEMENTS in perldelta
Updated Module::CoreList for v5.17.9
Add new release to perlhist
Finalise perldelta with updated module information
Update epigraphs with the one for v5.17.9
New perldelta template for v5.17.10
Bump to v5.17.10
Also skip io/eintr.t on MidnightBSD
Amend 'new perldelta' advice for Win32

test_porting is supported as target for both gcc and VC++ builds

win32/Makefile since 247c55c00b852ec1da004aff2c0e2d4b07af55ab

win32/makefile.mk since 106cf76e392294bc0fe10a3efa306d011f3b2e3c
add a missing 5 to the release announcement template
PATCH: [perl #116787] -Ox on Win64 Visual C 64 bit is flawed, switch to -O1

-Ox is missing -GF and -Gy and -Gs
http://blogs.msdn.com/b/branbray/archive/2005/07/08/437078.aspx
http://msdn.microsoft.com/en-us/library/8f8h5cxt%28v=vs.90%29.aspx
http://msdn.microsoft.com/en-us/library/59a3b321%28v=vs.90%29.aspx

So the remaining question is, use -O1 or use -O2 on VC 64? VC 32 bit uses
-O1, and that is also slightly faster on x64 too.
Simplify the defintiion of optimization flags in Windows makefiles

The setting of -O1 for release mode builds can be factored out of the
x86 and x64 cases following commit 688ea162f4.
Upgrade to Safe 2.35 from CPAN
Update Maintainers.pl for Safe 2.35
perlfunc: clarify that "do $file" isn't really like "eval `cat $file`"

Closes RT#116713.
Abolish STRANGE_MALLOC. Now all malloc()s are considered strange :-)

STRANGE_MALLOC was added in 5.002 beta 1 (4633a7c4bad06b47) as part of an
work around for typical mallocs, which had a bad interaction with perl's
allocation needs. Specifically, repeatedly extending an array and then
creating SV heads (such as when reading lines of a file into an array)
could end up with each reallocation for the array being unable to extend in
place, needing a fresh chunk of memory, and the released memory not being
suitable for use as more SV heads, so sitting unused. The solution was for
perl to recycle the old array body as SV heads, instead of returning it to
the system, passing the memory from the the AV code to the SV code using
offer_nice_chunk(), PL_nice_chunk and PL_nice_chunk_size.

STRANGE_MALLOC was actually a signal that the malloc() didn't need
protecting from itself, and to disable the work around.

offer_nice_chunk(), PL_nice_chunk and PL_nice_chunk_size were removed by
commit 9a87bd09eea1d037 in Nov 2010, without any ill effects, hence the
code used when STRANGE_MALLOC was *not* defined is essentially doing extra
work for no benefits.

From the lack of problems reported, one can assume that in the intervening
15 years malloc technology has got significantly improved, and it is probably
better to be honest with it, rather than trying to second guess it.

Hence remove all the non-STRANGE_MALLOC code, and leave everyone using the
much simpler code. See also
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2005-11/msg00495.html
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2013-01/msg00126.html
regcomp.c: Rmv comment ref to obsolete regnode
PATCH: [perl #116899]: jump on uninitialised value

The culprit had nothing to do really with the accuesed commit.
The function S_cl_or() tries to take the union of the code points
matched by its two inputs.  Both of those nodes must be ANYOF-like
(for bracketed character classes and synthetic start classes).  These
come in two flavors, one having extra fields in the struct after the
other one's.  That is used for locale ANYOFs and the synthetic start
class.  The first paramter to cl_or() is always one of these extended
ANYOFS, but the second parameter may be the shorter form

The function was failing to check if the second one was the longer form
before reading data from beyond the short-form's struct.  This could
cause a segfault, but that wasn't the symptom here.  Instead it copied
that data to the other paramter's struct.  valgrind had set that data to
indicate it was uninitialized, so when later it was accessed, we got
this error.

During much of the 5.17 series until the failing commit, more ANYOF
nodes were the larger size.  I presume that is why this commit showed up
the problem.
Remove trailing white-space from RMG document
Mark v5.17.9 as done in the release schedule