[perl #123963] "@<fullwidth digit>"

If an @ sign in a double-quoted string is not followed by a valid
identifier, then it is treated literally.  Or at least that is how it
was intended to work.

The lexer was actually not self-consistent.  It was treating non-ASCII
digits at valid identifiers in determining where the interpolation
started, but was not treating them as valid identifiers when actually
parsing the interpolated code.  So this would result in syntax errors,
and even crashes in some cases.

mg.c:Perl_magic_set: don't use 0 as "failed" gid_t

For [perl #123814] we added checking for grok_* parse failures in
magic_set for $), but used 0 as the placeholder result in those
cases (since we don't have an effective way to report an error for
this). (Gid_t)(-1) is a safer placeholder, since on many systems
that'll map to an explicit bad group id.

hints/os390.sh: z/OS doesn't work with an fd in file desc

Override Configure's determination, as this doesn't work.

hints/os390.sh: Update

hints/os390.sh: z/OS long long support

fix XXX comment for regcomp.c:S_reg

It actually does do the right thing: /(?(R0))/ and /(?(R00))/ both fall
through to give an appropriate error 'Switch condition not recognized'

grok_atoUV: don't make part of API

.. but keep available to extensions.

[perl #123814] replace grok_atou with grok_atoUV

Some questions and loose ends:

XXX gv.c:S_gv_magicalize - why are we using SSize_t for paren?
XXX mg.c:Perl_magic_set - need appopriate error handling for $)
XXX regcomp.c:S_reg - need to check if we do the right thing if parno
was not grokked

Perl_get_debug_opts should probably return something unsigned; not sure
if that's something we can change.

[perl #123814] stricter handling of numbers in regexp quantifiers

DBM_Filter/t/utf8.t: Generalize for other EBCDIC code pages

This worked for EBCDIC 1047, but not for other pages.  This commit
changes to use the tools created for the purpose to make it general.

dist/Net-Ping/t/450_service.t: Skip 2 tests on os390

These two tests are already skipped for hpux, and one for win32.  I'm
assuming the same issue here.

Module::CoreList: Fix to work on EBCDIC platforms

This creates a sort help that make a '?' always sort after the digits,
which it naturally does on ASCII platforms, but not EBCDIC

Devel::Peek:Peek.t: Fix to work on EBCDIC

dist/Safe/t/safeutf8.t: Generalize to non-ASCII platform

dist/Storable/t/code.t: Fixes to run under EBCDIC

dist/Storable/t/utf8.t: Fix to run under EBCDIC

perl.c: Don't read possibly zapped memory

See https://rt.perl.org/Ticket/Display.html?id=123748

The return of getenv() is a pointer to static storage which can legally
be overwritten at any time by other calls to access the environment,
even even another getenv().  (What actually happens varies from platform
to platform.)  Results of getenv() therefore either have to be acted on
immediately or copied to a safe area.  This commit does the latter for
this call in perl.c.  The static area was being held on to even into the
function call moreswitches() which does environmen handling, so was
vulnerable to this bug.

t/loc_tools.pl: Fix bug with locale tests in win32

This bug was introduced by commit
128e4113466e835078eb016709e5d23b86be3120.

Win32 doesn't have an LC_MESSAGES, so calls using that name failed.

Update comment in test to note possibly neccessary prerequisite.

op_reg_common.h: Add comment

embed.fnc: Change _warn_problematic_locale() function from public

Spotted by Daniel Dragan

perlrebackslash: Add, correct \b{} text

This fleshes out documentation about this new feature

perlrebackslash: Nit

perluniprops: Add text about using with older Unicode releases

This pod is generated by mktables.

Reinstate reverted "perlpod and spec: s/Latin-1/CP-1252/"

This reverts 1a3afb4f8c551b292b5b34f7244ed71f9ac01cfd which reverted
e2bb786192adfa315ea974b5f630d7040aa6f6ac, thus reinstating the latter.

In thinking about this and discussing it with rjbs, I (khw) realized
that this pod text really should go in to v5.22.  I made minor
clarifications and fixed the author name of the original commit.

Update David Wheeler's email address

AUTHORS: Add comment

lib/locale.t: White-space only

Indent inside new block formed in the previous commit.

Skip various locale tests when locales are not available

It is possible to compile Perl without locales, and some platforms may
not have them available properly.  These tests were failing under these
conditions.  This commit uses the new infrastructure in loc_tools.pl to
centralize the knowledge of how to determine if locales are available.

t/loc_tools.pl: Add fnc to see if locale category is available

It is possible for Perl to run on platforms that don't have locale
abilities, and it is possible to compile it to disable some or all of
locale processing.  This commit adds a function that for Perl code to
call that knows the nuances of detecting this.

perl.h: Make macro do nothing when LC_CTYPE not available

Otherwise things won't compile.

ext/POSIX/POSIX.xs: Convert do whiles into whiles

I don't know why these are do { ] while's, but with the correct
combination of compile flags (such as -DNO_LOCALE), and/or perhaps
platform, one or the other could be called the first time with nulls, so
they need to be straight while{}s to avoid segfaults.

t/test.pl: Actually change the code

Commit c42fde619a5536f7365e04b0ea569a21881b92ee claimed to do what this
commit actually does.  I forgot to merge the two commits before pushing.

t/test.pl: Remove use of more recent feature

This file is copied into the "threads" CPAN distribution, and the addition
of this modern feature (/a pattern modifier) required them to issue a
modified version of this file.  Since the effect of /a can easily be
achieved in other, though less clear, ways using longer established
syntaxes, use those with a clarifying comment.

See https://rt.perl.org/Ticket/Display.html?id=124013

Skip PL_warn_locale use unless compiled in

The use of this variable was inconsistent.  It was not dup'ed on thread
cloning unless LC_CTYPE is being used, but elsewhere it was.  This led
to segfaults on threaded builds.  Now it isn't touched anywhere unless
LC_CTYPE is used.

locale.c: Move statements properly within #if

The variables in these statments were undefined when compiled with
ccflag -DNO_LOCALE, because the declarations are skipped then.  Just
move them a few lines up so are within the same #if.

use re 'strict' doc changes

Add to perlexperiment; note that an alternative syntax has been
proposed; nits.

README.synology: Wrap too-long verbatim line

perlunifaq: Nits

pods: s/semantics/rules/ig in places

Juerd Waalboer suggested long ago that in documentation, using the term
"rules" is better than "semantics".  This changes some of the places
that had remained unchanged.  I looked at the still-remaining places,
and decided that it was best to leave them as-is.

Update Synology information

DSM-5.1 has perl-5.18.4 installed (or available through ipkg)
anyway, awesome to see it being more recent than 5.8.4

Re-fold long lines in INSTALL

I used a guide-width of 73

perldelta entry for 34a7e7b

Upgrade to threads 1.99

Make use64bitall distinctive from use64bitint on HP-UX

Merge branch 'maintpolicy' into blead

Update our policies w.r.t maintenance releases in the light of discussions
had during the release of 5.20.2, in particular:

http://www.nntp.perl.org/group/perl.perl5.porters/2014/12/msg224162.html
http://www.nntp.perl.org/group/perl.perl5.porters/2014/12/msg224120.html
http://www.nntp.perl.org/group/perl.perl5.porters/2015/01/msg224680.html

The lists of acceptable/unacceptable changes are essentially unchanged, but
the wording now emphasizes that it may not be desirable to cherry-pick
every eligible change, and states which types of change are the most
important ones to focus on.

The intention is to draw up a much shorter list of cherry-pick proposals in
the future. Hopefully, a much less daunting list of proposals will reduce
the difficulty in getting the required number of votes on the ones that
really matter and possibly reduce risk slightly in the process, but not
affect how worthwhile the contents of maintenance releases are.

maint policy: Note that some changes don't need voting on

Again, this is just a statement of the reality that I have experienced in
the course of releasing 5.20.1 and 5.20.2.

maint policy: Note that other voting mechanisms may be used instead of p5p

This simply reflects the reality of how 5.20.2's changes were voted on,
namely, by the use of the maint-5.20-votes branch.

maint policy: Reword/expand the ambiguous "as few changes as possible" phrase

This phrase caused much debate during the release of 5.20.2. A literal
interpretation of it would be just a version bump, which was clearly not
its intention. Debate ensued as to what was its real meaning, and the
consensus seemed to be that the list of "acceptable"/"unacceptable" types
of change was about right, but that not every eligible change should be
included. Not many committers are interested in reviewing a long list of
minor spelling corrections etc, causing a lack of interest in voting, and
an attendant risk of something important being missed amongst all the
"noise". The focus should mainly be on security / crash / regression /
installation issues, with the aim being to produce a worthwhile release
without needlessly increasing risk and/or burning people out. I hope the
new wording captures this.

maint policy: Move paragraph about controversial changes

The point was also raised during discussions over whether to include
perlunicook.pod in 5.20.2 that exceptions can be made to the rules under
the terms of "Rule 2" and the fact that the pumpking is acting on Larry's
behalf. However, this is probably best left being implicit, rather than
explicitly stating it. Exceptions should be exceptional; we don't want to
encourage them!

maint policy: Minor grammar and style change

maint policy: Separate build/installation issues from test failures

Also clarify a what kind of build/installation "issue" we are referring to.

maint policy: Note that old regressions are acceptable too

maint policy: Put notes about CPAN modules in one place

maint policy: No need to keep saying "are [NOT] acceptable" now

maint policy: Sort acceptable/unacceptable lists into rough priority order

This commit makes no changes to any of the wording.

maint policy: Separate acceptable/unacceptable changes into two litss

utfebcdic.h: Add comment

Add fixes for testing EBCDIC to blead

This branch contains fixes to test files to pass on both ASCII and
EBCDIC platforms.  Some of these are a couple years old, and have been
lingering in the EBCDIC branch until now.

These changes are all to core code that is not dual-lifed, and that
doesn't have any other complications.  Future commits will deal with
the ones left out of this commit.

Some commits generalize the test to work on any platform, including a
non-EBCDIC one, should there ever be one, unlikely as that may be.  The
subjects of these commits say something like "generalize to non-ASCII
platforms."

Some commits rely on EBCDIC and ASCII properties, and would have to be
revised if Perl were ever to work on a platform with some other
character set.  These typically mention EBCDIC in their subject lines.

Some commits merely skip some tests on EBCDIC platforms.  These were
because of several possible reasons.  One is that the test is specific
to a particular EBCDIC code page, and I did not wish to expend my time
in handling all those.  Another similar one is that there would be a
significant amount of work in converting the test, too much for me to
undertake, and I don't think the value added was worth it.  And some are
just because of the inherent qualities of EBCDIC don't fit.  For example
UTF-EBCDIC doesn't have the capacity to handle very large code points
that can be handled on 64-bit ASCII platforms.  Or the tests are just
for porting when we generate a Perl to ship; which we never will do on
an EBCDIC platform.

t/lib/croak/op: Fix to work on EBCDIC platforms

t/op/sprintf.t: Generalize for EBCDIC

This adds a mechanism for tests to be ASCII or EBCDIC specific

porting/checkcfgvar.t: Skip on EBCDIC platforms

This is failing on EBCDIC, probably because of sort order differences.
But we won't be packaging a release from one of these platforms; easiest
to just skip.

t/op/bop.t: Generalize for EBCDIC platforms

This also indents some lines that should have been indented or from a
newly formed block.

t/uni/case.pl: Fix to work on non-ASCII platforms

This involves changes to the three test files that call it

t/op/tie.t: Skip a couple tests on EBCDIC

These have different results on that platform.

t/op/inc.t: Generalize for EBCDIC

t/op/ver.t: Generalize for EBCDIC

t/lib/warnings/regcomp: SKIP some EBCDIC tests

The result varies depending on EBCDIC code page

lib/overload.t: Generalize for EBCDIC

PerlIO-encoding/t/encoding.t: Generalize for non-ASCII platform

t/lib/warnings/op: Skip some tests on EBCDIC

This splits a longer test into two smaller, the first is skipped on
EBCDIC because its result varies depending on code page.

t/lib/warnings/toke: Skip some tests on EBCDIC

The results depends on the particular EBCDIC platform being used, so I
don't think it is worth the effort.

POSIX/t/export.t: Generalize for non-ASCII platforms

Pod-Functions/Functions_pm.PL: Generalize for non-ASCII platforms

Hash-Util tests: Generalize for non-ASCII platforms

t/op/override.t: Generalize for non-ASCII platforms

t/op/chars.t: Generalize to not use code page specific

In EBCDIC, \c? resolves to the APC character.  We can use table lookup
to find out what that is on the current platform, without having to know
what code page we are using.

regexp_unicode_prop.t: Generalize for non-ASCII platforms

t/lib/feature/implicit: Generalize for EBCDIC platforms

ext/XS-APItest/t/hash.t: Generalize to run on non-ASCII platforms

t/lib/feature/implicit: Generalize for non-ASCII platforms

t/op/coreamp.t: Generalize for non-ASCII platfomrs

t/re/re_tests: Some tests are platform-specific

t/io/crlf.t: Generalize for non-ASCII platforms

ext/B/t/b.t: Generalize for non-ASCII platforms

t/op/warn.t: Generalize for non-ASCII platforms

re/reg_email.t: Generalize for non-ASCII platforms

This replaces all the hard-coded hex character values.  It uses the new
(?[ ]) notation.  I checked that the compiled regex matches the exact
same code points as before these changes.

ext/XS-APItest/t/svpeek.t: Extend to EBCDIC platforms

ext/XS-APItest/t/svpv_magic.t: Generalize for non-ASCII platforms

lib/utf8.t: Generalize for non-ASCII platforms

This includes choosing a different code point that has 3 bytes in both
UTF-8 and UTF-EBCDIC, so that the pos numbers work for both.

t/uni/parser.t: Extend to EBCDIC platforms

t/uni/method.t: Extend to EBCDIC platforms

I couldn't figure out a way to not use the hard-coded values

t/op/magic.t: Generalize for non-ASCII platforms

t/io/through.t: Generalize for EBCDIC platforms

This uses hard-coded values for EBCDIC because of the shell issues

t/op/goto.t: Generalize for non-ASCII platforms

t/re/pat.t: Generalize for EBCDIC

t/uni/overload.t: Generalize for non-ASCII platforms

t/uni/method.t: Generalize for non-ASCII platforms

t/op/utf8magic.t: Generalize for non-ASCII platforms

t/op/evalbytes.t: Generalize for non-ASCII platforms