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

t/op/utfhash.t: Fix to work on EBCDIC 1047

This .t thought it could have an __END__ in the middle of DATA input,
and the first read would read in up to that, and the second would read
the rest.  In bisecting, I couldn't find a time when this ever worked.
Now this has a marker, and does a split on that marker, choosing the
first or second half depending.

Note that this only works on ASCII and EBCDIC 1047 platforms.  It could
be extended for the other code pages Perl purportedly supports.

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

t/op/split.t: EBCDIC fixes

re/pat_advanced.t: EBCDIC fixes

This includes not skipping some EBCDIC that formerly was, since we now
have testing infrastructure that makes this easy.

t/io/utf8.t: EBCDIC fixes

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

lib/feature/bundle: Generalize for non-ASCII platforms

XS-APItest/t/fetch_pad_names.t: Skip if EBCDIC

This could be ported, but there's a lot of stuff to convert

ext/XS-APItest/t/utf8.t: Fix so passes EBCDIC

This involves skipping much of the tests, because it would be painful to
generalize for the different EBCDIC code pages.

ext/re/t/re_funcs_u.t: Generalize for non-ASCII platforms

t/op/print.t: Skip an EBCDIC test

This could be fixed (the values would probably change depending on the
code page), but the code that would get exercised is unlikely to vary
depending on character set.

op/chop.t: Fix for EBCDIC

One test is skipped because the code point is not representable on
EBCDIC platforms.  Other tests are modified to work on EBCDIC.

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

This had code that attempted this, but it was wrong.  The conversion to
EBCDIC must be done before the \U, or similar.

Skip some porting tests under EBCDIC

EBCDIC won't work on these because of inherent differences from ASCII,
including a different sort order.

For porting/regen.t, we use the shipped parsing rules on EBCDIC platforms

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

t/op/quotemeta.t: EBCDIC fixes

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

t/uni/class.t: Generalize to work on non-ASCII platforms

feature/unicode_strings.t: Generalize to work on non-ASCII platforms

lib/dumpvar.pl: Generalize for non-ASCII platforms

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

This converts the hard-coded character numbers to native, so will work
on any platform.  It also adds some tests, and improves some test names

APItest/t/handy.t: Generalize for non-ASCII platforms

t/base/lex.t: Generalize for EBCDIC platforms

\xE2 is 'S' in EBCDIC, and so is ASCII there.  We need something that is
an alpha on both platforms that isn't ASCII.  \xDF works.

Also, 65 may not be "A" on a non-ASCII platform, so use 65 instead of
'A' where 65 is wanted

lib/Unicode/UCD.t: White-space only

Properly indent within a block

perldelta for previous commit (threads upgrade)

Upgrade to threads 1.98

lib/Config.t: Skip tests that are invalid on os390

t/comp/require.t: No longer needed to skip on EBCDIC

t/uni/write.t: Don't skip EBCDIC tests

This now passes on os390

t/lib/warnings/utf8: Update skip message

It is not that EBCDIC platforms don't check for malformedness; it is
that a different message gets generated on them, and it's too much
bother to figure it out for each such platform.