Add cross-reference to perldata in scalar's documentation

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810156

perlrun: note the existence of find's -delete switch

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776614

Bump $File::Copy::VERSION

File::Copy: add a warning about flushing writes

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494590

perl.pod: @INC is being displayed as intended

The previous presentation looked a bit like an incomplete placeholder
expansion.

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=246542

Tick off 5.22.2

5.22.2 today

(Manually cherry picked from commit 72ccbefa77099a0bf1b7c2cb9f29685ed7d9938d)

Import 5.22.2's perldelta

Import 5.22.2's Module::CoreList data

trivial s/or/of/ doc patch

perlpolicy: add Sawyer X to list moderators

bump version to v5.24.0-RC3

corelist: silence deep recursion warning with %version

Remove some data detritus from CoreList

Document exports policy within POSIX

Correct lround situation comment in POSIX

bump perl version to v5.24.0-RC2

corelist: update Time::HiRes for v5.24.0

Synchronize with CPAN Time-HiRes 1.9733

lib/perl5db.pl: Fix pod error.

Apple Xcode / clang version updates and additions

darwin (OS X) hints comments alignment

(preparing for the next change)

Time-HiRes version bump

[PATCH] Time-Hires: Fix declaration-after-statement error with darwin threads

rt #113856: the flag -Werror=declaration-after-statement is seemingly
not working for clang (in OS X, not yet tested elsewhere), but working
as intended for gcc.  Since the system cc for OS X is clang (via Apple),
this failure to fail has been masked.

To restate: without this patch the Time-HiRes does not build in OS X
with gcc under usethreads.

Regenerate Configure and related parts after backports

perl5.git is now in sync with metaconfig.git commit
7c34fa4e8142642c6e2978f0307e925898465f58

Bring Configure back into sync again with meta

Work done at the QAH in Rugby.
Multi-thanks to Aaron for helping out here. You're doing a great job!

Allow Encode to be built on static perls

Previously there were build failures because cp1252 was defined both
in the default set of encodings an in the byte set.

Revert "document that sigs in future may not populate @_"

This reverts commit 19d6c3854e96d89bf4dc2d874df433beac27ee8b.

Fix some pod errors

These were discovered while testing the Pod::Checker that is intended to
be used in 5.25.

[perl #127936] fix typo

perldelta for ab462c7d2d

[perl #127894] ensure alignbytes is correct for -Dusequadmath

Correct typo in JJORE's name in todo.pod.

Avoid passing non-literal to format function

This avoids the following error, reported by Jitka Plesníková
<[email protected]> in a test of RC1:

op.c: In function 'Perl_ck_ftst':
op.c:9754:58: error: format not a string literal and no format arguments [-Werror=format-security]
                 Perl_warner(aTHX_ packWARN(WARN_SYNTAX), array_passed_to_stat);

In addition, the string in question is now made const.

document that sigs in future may not populate @_

Give people a heads up that in the next major perl release, subroutine
signatures may no longer populate @_ by default.

See http://nntp.perl.org/group/perl.perl5.porters/235332.

perldelta: Remove error/warning explanations

Only the text of these should be present in a delta, with a link to the
full explanation.  Most of perldelta conformed to this, but not all.

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.