perldelta: Add some C<>

perldelta: Clarifications, corrections, wordsmithing

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

Add perldelta for d9fc04ee

perldelta: IO-Compress is a dist, no link possible

perldelta: generate the module update section

perldelta: various fixes

 * behaviour -> behavior
 * =over -> =over 4
 * Add =items for consistency
 * Capitalization fixes

perldelta: Fix typo

perldelta: Revise wording

Some of this was suggested by Jarkko Hietaniemi

perldelta: Remove typo extra '/'

This fixes the 5.24 part of [perl #127899].

perldelta: minor tweak to fix awkward prose

(Thanks, Ed Avis!)

patchlevel: we are now RC1

remove the v5.23.x perldeltas

perlpolicy: update the supported versions for v5.24 on

perlhist: add v5.24.0 data

corelist: set a (tentative) release date for 5.24.0

fix IO::Handle documentation mangled by a manually applied patch

perllocale: Unicode has changed their data; fix references

We say something here that is no longer true; update it.

perldelta: Some minor fixes.

This includes deleting some bug fixes for things introduced in the 5.23
series, and so not relevant to a dot zero perldelta

pod/perldelta: Fixes to pedantic failures

perldelta: Add note about recent doc change

Merge branch 'release-5.24' into blead

This commit is just prep, turning blead into the branch from which
v5.24.0 will be released, after suitable testing.

CoreList: update for v5.24.0

fix versions of generated perldelta

put perl5240delta into place

regen META.json for v5.24.0-RC

regen: B::Op_private and uconfig.h

version bump: this is now v5.24.0-RC0!

perldelta: merge in perl5239delta

perldelta: remove unneeded entries, do more merge and sort

perldelta: merge in changes from perl5238delta

perldelta: merge in changes from perl5237delta

perldelta: merge in changes from perl5236delta

perldelta: merge in changes from perl5235delta

perldelta: merge in changes from perl5234delta

perldelta: merge in changes from perl5233delta

perldelta: merge in changes from perl5232delta

perldelta: merge in changes from perl5231delta

perldelta: bootstrap perl5240delta with perl5230delta

Add 5.22.2-RC1 epigraph

5.22.2-RC1 today

PATCH: [perl #127708] segfault in "$!" in threads

This was showing up on Darwin because its setlocale is particularly not
thread safe.  But the problem is more generic.  Using locales just
isn't a good idea in a threaded application, as locales are
process-wide, not thread-specific.  Calling setlocale() changes the
locale of all threads at the same time.  Further the return of
setlocale() is a pointer to internal storage.  If you call setlocale()
just to learn what it currently is without actually changing the locale,
there is no guarantee that another thread won't interrupt your thread,
switching the locale to something else before you've had a chance to
copy it somewhere else for safekeeping, and the internal storage may
have been freed during that interruption, leading to things like
segfaults.

This is a problem that has been around in the locale handling code for a
long time.  I don't know why it hasn't shown up before, or maybe it has
and is not reproducible because it's timing dependent, and so any
problems didn't have tickets written for them, or were rejected as not
reproducible.

But the problem has been made worse in recent releases.  Only fairly
recently has perl changed so this problem can occur in programs that
don't use locale explicitly: ones that don't 'use locale' nor call
setlocale().  This ticket is for such a program that gets a
locale-related segfault, without ever touching locales itself.

I have done an audit of the perl source, looking for all such
occurrences, and this patch fixes all of them that I found.  The only
other ones, besides "$!", is in converting to/from UTF-8 in cygwin.c.
In all such cases, perl briefly switches the locale, does an operation,
then switches back.  The solution here is to add mutexes to make these
areas of code uninterruptible critical sections, so that they can rely
on having the locale be what they expect it to be during the entirety of
the operation, and can't have a setlocale() from another thread free
internal storage.  But this is not a general solution.  A thread
executing these sections can interrupt some other thread doing a
setlocale() and zap that.  However, we have long cautioned against doing
setlocales() in a thread, and that caution was strengthened in a commit
made yesterday, fc82b82ef4784a38877f35f56ee16f14934460ce.

The current commit should make safe all threaded programs that don't use
locales explicitly.

It's too close to the 5.24 release to do the rearchitecting required for
a general solution.  That would involve adding more critical sections.

POSIX 2008 introduced new locale handling functions that are
thread-safe, and affect only a single thread, and don't require mutexes.
The ultimate solution would be to use those tools where available, and
to hide from the outer code which set is being used.  Thus, perl would
be thread-safe on such platforms, while remaining problematic on older
ones, though fixed so segfaults wouldn't occur.  Tony Cook believes we
could emulate the newer behavior on all platforms at a significant
performance penalty.  I think this would require a lot of code, and
suspect there would be glitches in it for XS code.  But he may have
some ideas about how to do it simply.  In any case, this has to wait
until post 5.24.

Three other notes:

It seems to me that the cygwin code could be replaced by equivalent code
that doesn't use locales at all.  The comments in the source seem to
even indicate that.  I'll look into doing this in 5.25.

Another possible reason that this hasn't shown up in earlier perls is
that the problems may have been entirely affecting I/O operations and
there are already mutexes involving I/O, and so those could be
inadvertently protecting from, or at least minimizing, the problems
found here.  I haven't investigated to verify this.

This commit doesn't add a test.  I am asking on p5p for assistance in
writing one

Add locale mutex

This adds a new mutex for use in the next commit for use with locale
handling.

move perf test from re/pat.t to re/speed.t

These days we generally put re tests which rely on timing in a separate
file, t/re/speed.t; move a recently-added test there.

new perf test in pat.t: avoid timing failure

A new performance test in re/pat.t added by v5.23.9-58-gd14d585 could
occasionally fails to a timing issue. It was checking that the the
test took less than 1 sec to run; but since the clock usually has a
granularity of 1 sec, it could fail if the test ran over a tick boundary.

Change the condition to <= 1 sec, and increase the time the test takes on
a bad perl - it was taking 4sec on my system; it now takes about 14sec,
so there's less chance of a bad perl passing.

Strengthen cautions about locale use with threads

This comes from our increased understanding of their perils, given
ticket #127708

More generalized fix for #127855, overallocate in SvGROW and not just sv_grow()

If we overallocate in SvGROW() and not just sv_grow() we can ensure
we have more cases where we can COW. We need to ensure we always
have room for a null and a reference count.

fix #127855, in Perl_sv_setpvn() we have to overallocate to enable COW

We need to overallocate by 2 to do COW strings. One for the null,
one for the refcount.

test for #127855 - Slowdown in m//g on COW strings of certain lengths

Revert "Make instr() a macro"

This reverts commit fea1d2dd5d210564d442a09fe034b62f262f35f9 due to it
causing problems so close to the release of 5.24.  See
https://rt.perl.org/Ticket/Display.html?id=127852

update security contact information.

Point out that the security-reporting email address now creates an RT
ticket. Also, consolidate this information purely within perlsec.pod, and
make all the other places link to it with L<>.

Add another missing link to epigraphs.pod

(perl #126162) improve stat @array handling

- warn on lexical arrays too

- limit the warning to under C<use warnings 'syntax';>

- test the warnings

- include the (correct) variable name where possible

error messages vary between platforms, use errno values instead

add the new stat(@array) diagnostic to perldiag

(perl #126162) warn if stat() is called on an array

5.22.2 should appear this month, starting with RC1 on Sunday 10th

Add SILENT_NO_TAINT_SUPPORT to S_Internals_V ()

NO_TAINT_SUPPORT was added in 3b0e4ee2077, but SILENT_NO_TAINT_SUPPORT was overlooked.

Get -Accflags=-DPERL_MEM_LOG compiling again

It had rotted a bit Well, more than one probably.

Move the declarations of the functions Perl_mem_log_alloc etc from handy.h
into embed.fnc where whey belong, and where Malloc_t will have already
been defined.

ss_dup: make new savestack have SS_MAXPUSH extra

This fixes RT #perl #127799

My commit v5.23.7-261-g3caf026 made PL_savestack_max claim to have
allocated less than had actually been claimed (by a margin of SS_MAXPUSH).
This made the 'check whether the stack needs extending code' slightly
simpler, and errs on the side of safety. Except:

Perl_ss_dup(), when duplicating the savestack, makes the new stack
PL_savestack_max in size, which is large enough to duplicate the existing
stack, but the new stack no longer has a SS_MAXPUSH margin at the top.

The dSS_ADD family of macros work by assuming there is always such a
margin: they push their args onto the stack and only then check whether
the stack needs growing. This makes the code much more efficient, but of
course breaks if no margin is present.

Follow-up to previous Solaris/S_regmatch commit

PL_charclass is the thing being temporarily #defined to something else, so
it's the thing that needs #undeffing at the end, not pl_charclass_dup.

Doesn't make any difference at the moment, but would if at some point
a function following S_regmatch() started making use of PL_charclass.

S_regmatch(): work around Solaris optimiser bug

Recently these test scripts started failing on Solaris i386 with
-Duse64bitall:

    re/charset.t
    re/subst.t
    re/substT.t
    re/subst_wamp.t

The first failure is due to a Solaris Studio optimiser bug; this commit
works around that failure. It may or may not also fix the other failures
(all tests pass now on the development box I was using, but I didn't
confirm whether the other tests failed before the fix).

The basic problem is that within the main while loop in S_regmatch(),
the expression PL_charclass['\n'] returns the wrong value.

Looking at the disassembled code, it appears that looking up this value
just before the while loop correctly does it by getting the address of the
global array PL_charclass, adding 40 to it (ord('\n')*sizeof(U32)), then
dereffing it.

Within the loop however, it just reads the value from a local var. The
optimiser is under the misapprehension that this value has previously been
read in and assigned to a local var, but it certainly hasn't been at the
point where the while loop is first entered.

This commit works round the problem on builds with -Duse64bitall and the
bad version of Solaris Studio compiler (12.3), by making a copy of
PL_charclass's address.

This is a bit of hack. For one thing, I don't know whether other versions
of the compiler also need this workaround.

The failures were seen on a 32-bit system with -Duse64bitall: this created
a 64-bit executable (i.e. with 64-bit pointers) with the -m64 compiler
flag. I would speculate that the bug in the compiler relates to to
this particular circumstance (i.e. the bug might not appear for a build
done on a 64-bit OS host with or without -Duse64bitall).

epigraphs.pod - Add missing link, plus minor formatting corrections

[perl #127760] add CUSTOMIZED for File-Path

https://github.com/rpcme/File-Path/pull/34

[perl #127760] skip the Win32 UNC path tests on Win2k and older

Windows 2000 doesn't seem to support a UNC path as a current
directory - setting the current directory to a UNC path and then
trying to stat(".") results in a file not found or similar error.

This does work on Windows XP and later.

avoid mis-mangled name references on threaded C++ builds

g++ on recent darwin appears to be clang++ in disguise, and so
supports the TSA decorations, but the wrappers we define don't have
explicit extern "C" linkage (which perlapi.h does have).

Under C++ Time::HiRes wraps its includes in extern "C" { }, and
so references unmangled names for the perl_tsa_mutex_*() wrappers,
but since util.c never sees an extern "C" for those functions it
produces mangled names, causing undefined references in Time::HiRes.

Detected by a smoke run againt a smoke-me branch:

http://www.nntp.perl.org/group/perl.daily-build.reports/2016/03/msg190183.html

Longer term the TSA decorations should probably be probed for in Configure
and the wrapper declarations moved to embed.fnc

note for detecting crypt() on Cygwin

don't test crypt()s tied fetch count if we don't have crypt()

As of libcrypt 1.3, crypt() isn't detected on cygwin unless you install
libcrypt-devel, and this test failed.

restore incorrectly deleted note

fix debug sprintf issue

Export lround() from POSIX

This function was implemented as of 5.21.4, but not exported (even by
request). It's too late in the 5.24 freeze for it to be exported by default,
or as part of a tag, but we can at least make it available to those who want
to import it by name.

run regen/uconfig_h.pl

For some reason when the memmem probe was added, uconfig.h wasn't
regenerated correctly. Probably because it doesn't get run by default
with 'perl regen.pl' - which in turn is because it requires a shell
to run.

Improve code comments for some ctx stuff

* in pp_return(), some comments were out of date about how
  leave_adjust_stacks() is called ;
* add a comment to all the functions that pp_return() tail-calls to the
  effect that they can be tail-called;
* make it clearer when/why OPf_SPECIAL is set on OP_LEAVE;
* CXt_LOOP_PLAIN can be a while loop as well as a plain block.

RT #127786: assertion failure with eval in DB pkg.

Normally a cloned anon sud has a NULL CvOUTSIDE(), unless that
sub can contain code that will do an eval.
However, calling eval from within the DB package pretends that the eval
was done in the caller's scope. which then trips up on the NULL
CvOUTSIDE().

ts)

re_exec_indentf,re_indentf: silence warnings

Pass the right types to printf.

For re_exec_indentf(), really the type of the depth arg should be changed
so that it and the depth var are consistent throughout regexec.c, but
that's probably something for post-5.24.

silence -Wparentheses-equality

Clang has taken it upon itself to warn when an equality is wrapped in
double parentheses, e.g.

    ((foo == bar))

Which is a bit dumb, as any code along the lines of

    #define isBAR (foo == BAR)
    if (isBAR) {}

will trigger the warning.

This commit shuts clang up by putting in a harmless cast:

    #define isBAR cBOOL(foo == BAR)

silence warnings in inline.h on Win64 VC build

c:\p523\src\inline.h(211) : warning C4267: 'function' : conversion from 'size_t'
 to 'I32', possible loss of data
c:\p523\src\inline.h(212) : warning C4267: 'function' : conversion from 'size_t'
 to 'I32', possible loss of data
c:\p523\src\inline.h(421) : warning C4244: '=' : conversion from '__int64' to 'I
32', possible loss of data
c:\p523\src\inline.h(423) : warning C4244: '=' : conversion from '__int64' to 'I
32', possible loss of data

To fix the warnings at line 211 and 212, change the func to use a signed
ptr length type. Although on x64, a 64b to 64b move instruction is 1 byte
longer than a 32b to 32b move, so this commit adds a couple more bytes of
machine code to the interp, but PVs len and cur are STRLEN, which is 64b
on 64b OS, so something bad would happen if a very large off arg was
passed to Perl_utf8_hop that was trucated to 32b, hence casting to silence
the warning isn't appropriate, instead a bigger type is needed.

S_cx_pushblock, a 8*(2^32), or 32 GB long perl stack malloc block is
unrealistic. A 32 GB mark stack is infinite recursion. Cast away the
warnings.

Move the zeroing back before the dladdr() call.

[perl #127773: Assertion failure in perl built with Dusecbacktrace]

ODBM_File version bump

[perl #127751] error building ODBM_File on Windows, perl 5.23.9

No POSIX open in Win32, broken by ed6087adbd9c90b59cf3f08af7c23a947c00bf69

Use the PerlLIO_open3 as suggested by Tony Cook, use the same trick as POSIX.xs

Revert "configure.com update for newlocale, freelocale, and uselocale."

This reverts commit f0e3aef8abfe33645e0b9682e5f5ec7090de749f.

The changes had actually already been done by a regen at
0f2b45c74307980ff2, so these were duplicates.

improve perldiag implicit close text still further

Suppress another empty \N{} warning in pat_advanced.t.

Follow-up to d8d26cacf9f6b2fbd476.

Add probe for memmem

Suggest having the previous release ready.

Each time I do a release, I find myself scrambling to download the
tarball of the previous release, and install it so it can be compared
to the release that's worked on. Added a paragraph as a reminder to
that before the day of the release.

Add 's' and 'S' to list of ANSI C portable filename characters.

For: RT #127783.  Thanks to Jim Davis for report.

improve perldiag implicit close text further

PATCH: [perl #123417] Deprecate empty \N{}

t/re/re_tests: Add missing \ escape to a test

This just happened to work, but the backslash should be escaped, as it
is evaluated in qq context

stop lc() etc accidentally modifying in-place.

As an optimisation, [ul]c() and [ul]cfirst() sometimes modify their
argument in-place rather than returning a modified copy.

This should only be done when there is no possibility that the arg is
going to be reused. However, this fails:

    use List::Util qw{ first };
    my %hash = ( ASD => 1, ZXC => 2, QWE => 3, TYU => 4);
    print first { lc $_ eq 'qwe' } keys %hash;

which prints "qwe" rather than "QWE".

Bascally everything in perl that sets $_ or $a/$b and calls a code block
or function, such as map, grep, for and, sort, either copies any PADTMPs,
turns off SvTEMP, and/or bumps the reference count.

List::Util doesn't do this, and it is likely that other CPAN modules
which do "set $_ and call a block" don't either.

This has been failing since 5.20.0: perl has been in-placing if the arg is
(SvTEMP && RC==1 && !mg) (due to v5.19.7-112-g5cd5e2d).

Make the optimisation critera stricter by always copying SvTEMPs.
It still allows the optimisation if the arg is a PADTMP - I don't know
whether this is unsafe too.

Perhaps we can think of something better after 5.24?

improve perldiag implicit close text

Mark unexpectedly passing TEST -deparse tests

About 270 test files formerly marked as "expected to fail under
"./TEST -deparse" now pass. We must be doing something right :-)

Remove them from the list of expected failures.

Conversely, there are also 174 failing tests that are aren't marked
as expected to fail, so we're probably doing something wrong too :-(.

List perl.develop-help.com in the RMG regarding smoke reports.

[perl #127764] Perl with '-Dusecbacktrace' doesn't compile on darwin

Fix a thinko in 22ff3130.

[perl #127765] Fix bogus $File::Spec::AmigaOS::VERSION

';' a single bitflip away from '3', which must have happened before
e46aa1dd got committed, since the SHA-1 hashes are all consistent.

Point out that at some stage, porting tests will fail.

This trips me each and every time I make a release. Whenever the
release manager guide calls for a compile/make test cycle, I run
"make test_harness", and this fails at this stage, because Module::CoreList
has not been updated yet (the next action described in the release
managers guide is updating Module::CoreList).

I also removed some suboptimal advice I've written here in the past.

Maintainers.pl updates

Integrate podlators 4.07

Bump version in various places

New perldelta