perlio.c: Generalize for EBCDIC

This code had the hex constants for CARRIAGE RETURN and LINE FEED
hard-coded in.  It appears to me from the comments that '\r' and '\n'
are not suitable to use instead.  This commit changes the constants to
use the native values instead.

unicode_constants.h: Add #defines for CR, LF

regcomp.c: In EBCDIC [i-j] exclude also ASCII

i and j are not adjacent in EBCDIC.  This excluded any alphabetic
characters between them, but allowed other ascii ones.

utf8.c: Don't use slower general-purpose function

There is a macro that accomplishes the same task for a two byte UTF-8
encoded character, and avoids the overhead of the general purpose
function call.

utf8.c: Don't do ++ in macro parameter

The formal parameter gets evaluated multiple times on an EBCDIC
platform, thus incrementing more than the intended once.

utf8.c: Use macro instead of duplicating code

There is a macro that accomplishes this task, and is easier to read.

utf8.h: Clarify comments

utf8.c: Avoid unnecessary UTF-8 conversions

This changes the code so that converting to UTF-8 is avoided unless
necessary.  For such inputs, the conversion back from UTF-8 is also
avoided.  The cost of doing this is that the first swatches are combined
into one that contains the values for all characters 0-255, instead of
having multiple swatches.  That means when first calculating the swatch
it calculates all 256, instead of 128 (160 on EBCDIC).

This also fixes an EBCDIC bug in which characters in this range were
being translated twice.

utf8.c: No need to check for UTF-8 malformations

This function assumes that the input is well-formed UTF-8, even though
until this commit, the prefatory comments didn't say so.  The API does
not pass the buffer length, so there is no way it could check for
reading off the end of the buffer.  One code path already calls
valid_utf8_to_uvchr(); this changes the remaining code path to correspond.

utf8.c: Fix so UTF-16 to UTF-8 conversion works under EBCDIC

utf8.h, utfebcdic.h: Add #define

pp.c: White-space only

Make a ternary operation more clear

Fix valid_utf8_to_uvchr() for EBCDIC

t/test.pl: Add comment about EBCDIC

Fix EBCDIC bugs in UTF8_ACUMULATE and utf8.c

regcomp.c: Fix bug in EBCDIC

The POSIXA and NPOSIXA regnodes need to set the bits on only the ASCII
code points, but under EBCDIC those code points are not 0-127.

toke.c: Simplify some code

We don't have to test separately for lower vs uppercase here, as
upper/lower case A-Z and a-z are not intermixed in the gaps in A-Z and
a-z under EBCDIC.

sv.c: Make less ASCII-centric

dump.c: Make less ASCII-centric:

This has the added advantage of being clearer as to what is going on.

hv.c: Stop being ASCII-centric

This uses macros which work cross-platform.  This has the added advantge
what is going on is much clearer.

utfebcdic.h: Change 'unsigned char' to U8

This is for consistency with the rest of Perl

regen/regcharclass.pl: Make more EBCDIC-friendly

This commit changes the code generated by the macros so that they work
right out-of-the-box on non-ASCII platforms for non-UTF-8 inputs.  THEY
ARE WRONG for UTF-8, but this is good enough to get perl bootstrapped
onto the target platform, and regcharclass.pl can be run there,
generating macros with correct UTF-8.

utfebcdic.h: Add (UV) cast

The operand of this macro is implicitly a UV.  Make sure that it is.

handy.h: Allow bootstrapping to non-ASCII platform

This adds a bunch of macros and moves things around to support
conditional compilation when Configure is called with
-DBOOTSTRAP_CHARSET.  Doing so causes the usual macros that are
table-driven to not be used, since the table may not be valid when
bringing Perl up for the first time on a non-ASCII platform.

This allows it to compile using the platform's native C library ctype
functions, which should work enough to compile miniperl, and allow the
table to be changed to be valid.  Then Configure can be re-run to not
bootstrap, and normal compilation can proceed

toke.c: Remove EBCDIC dependency

toke.c: Remove character set dependency

Instead of hard-coding the bit patterns that comprise the Byte Order
Mark in the UTF-8 or UTF-EBCDIC encodings, use the generated ones for
the current platform.

This removes some EBCDIC-only code.

unicode_constants.h: Add #defines for Byte Order Mark

These will be used in future commits

utfebcdic.h: Add comment

utf8.h: Clean up and use START_MARK definition

The previous definition broke good encapsulation rules.  UTF_START_MARK
should return something that fits in a byte; it shouldn't be the caller
that does this.  So the mask is moved into the definition.  This means
it can apply only to the portion that creates something larger than a
byte.  Further, the EBCDIC version can be simplified, since 7 is the
largest possible number of bytes in an EBCDIC UTF8 character.

utf8.h: Move #includes

These two files were only being #included for non-ebcdic compiles; they
should be included always.

utfebcdic.h: Remove extra parameter expansions

These two macros were improperly expanding the parameters as well as
defining the operation, leading to compile errors.

utf8.h: Simplify UTF8_EIGHT_BIT_foo on EBCDIC

These macros were previously defined in terms of UTF8_TWO_BYTE_HI and
UTF8_TWO_BYTE_LO.  But the EIGHT_BIT versions can use the less general
and simpler NATIVE_TO_LATIN1 instead of NATIVE_TO_UNI because the input
domain is restricted in the EIGHT_BIT.  Note that on ASCII platforms,
these both expand to the same thing, so the difference matters only on
EBCDIC.

handy.h: Remove extraneous parens

utf8.c: Use more clearly named macro

In the case of invariants these two macros should do the same thing,
but it seems to me that the latter name more clearly indicates what is
going on.

Add macro OFFUNISKIP

This means use official Unicode code point numbering, not native.  Doing
this converts the existing UNISKIP calls in the code to refer to native
code points, which is what they meant anyway.  The terminology is
somewhat ambiguous, but I don't think it will cause real confusion.
NATIVE_SKIP is also introduced for situations where it is important to
be precise.

toke.c: white space only

toke.c: Don't remap \N{} for EBCDIC

Everything but \N{U+XXXX} is now in native,

utf8.c: Stop using two functions

This is in preparation for deprecating these functions, to force any
code that has been using these functions to change.
Since the Unicode tables are now stored in native order, these
functions should only rarely be needed.

However, the functionality of these is needed, and in actuality, on
ASCII platforms, the native functions are #defined to these.  So what
this commit does is rename the functions to something else, and create
wrappers with the old names, so that anyone using them will get the
deprecation when it actually goes into effect: we are waiting for CPAN
files distributed with the core to change before doing the deprecation.

According to cpan.grep.me, this should affect fewer than 10 additional
CPAN distributions.

Convert uvuni_to_utf8() to function

Code should almost never be dealing with non-native code points

This is in preparation for later deprecation when our CPAN modules have
been converted away from using it.

Deprecate utf8_to_uni_buf()

Now that the tables are stored in native order, there is almost no need
for code to be dealing in Unicode order.

According to grep.cpan.me, there are no uses of this function in CPAN.

Deprecate valid_utf8_to_uvuni()

Now that all the tables are stored in native format, there is very
little reason to use this function; and those who do need this kind of
functionality should be using the bottom level routine, so as to make it
clear they are doing nonstandard stuff.

According to grep.cpan.me, there are no uses of this function in CPAN.

utf8.c: Swap which fcn wraps the other

This is in preparation for the current wrapee becoming deprecated

utf8.c: Skip a no-op

Since the value is invariant under both UTF-8 and not, we already have
it in 'uv'; no need to do anything else to get it

utf8.c: Move comment to where makes more sense

APItest: Test native code points, instead of Unicode

Don't refer to U+XXXX when mean native

These messages say the output number is Unicode, but it is really
native, so change to saying is 0xXXXX.

Convert some uvuni() to uvchr()

All the tables are now based on the native character set, so using
uvuni() in almost all cases is wrong.

handy.h: White space only

t/test.pl: Allow native/latin1 string conversions to work on utf8.

These functions no longer have the hard-coded definitions in them,
but now end up resolving to internal functions, so that new encodings
could be added and these would automatically understand them.

Instead of using tr///, these now go character by character and
converting to/from ord, which is slower, but allows them to operate on
utf8 strings.

Peephole optimization should make these essentially no-ops on ascii
platforms.

t/test.pl: Simplify ord to/from native fcns

This commit changes these functions from converting to/from a string to
calling functions which operate on ordinals instead that are in the
utf8:: namespace.

Make casing tables native

These are final tables that haven't been converted to native character
set casing.

utfebcdic.h: Remove trailing spaces

EBCDIC has the unicode bug too

We have not had a working modern Perl on EBCDIC for some years.  When I
started out, comments and code led me to conclude erroneously that
natively it supported semantics for all 256 characters 0-255.  It turns
out that I was wrong; it natively (at least on some platforms) has the
same rules (essentially none) for the characters which don't correspond
to ASCII ones, as the rules for these on ASCII platforms.

A previous commit for 5.18 changed the docs about this issue.  This
current commit forces ASCII rules on EBCDIC platforms (even should there
be one that natively uses all 256).  To get all 256, the same things
like 'use feature "unicode_strings"' must now be done.

handy.h: Solve a failure to compile problem under EBCDIC

handy.h is included in files that don't include perl.h, and hence not
utf8.h.  We can't rely therefore on the ASCII/EBCDIC conversion
macros being available to us.  The best way to cope is to use the native
ctype functions.  Most, but not all, of the macros in this commit
currently resolve to use those native ones, but a future commit will
change that.

handy.h: Simplify some macro definitions

Now, only one of the macros relies on magic numbers (isPRINT), leading
to clearer definitions.

handy.h: Combine macros that are same in ASCII, EBCDIC

These 4 macros can have the same RHS for their ASCII and EBCDIC
versions, so no need to duplicate their definitions

This also enables the EBCDIC versions to not have undefined expansions
when compiling without perl.h

Deprecate NATIVE_TO_NEED and ASCII_TO_NEED

These macros are no longer called in the Perl core.  This commit turns
them into functions so that they can use gcc's deprecation facility.

I believe these were defective right from the beginning, and I have
struggled to understand what's going on.  From the name, it appears
NATIVE_TO_NEED taks a native byte and turns it into UTF-8 if the
appropriate parameter indicates that.  But that is impossible to do
correctly from that API, as for variant characters, it needs to return
two bytes.  It could only work correctly if ch is an I8 byte, which
isn't native, and hence the name would be wrong.

Similar arguments for ASCII_TO_NEED.

The function S_append_utf8_from_native_byte(const U8 byte, U8** dest)
does what I think NATIVE_TO_NEED intended.

Remove remaining calls of NATIVE_TO_NEED

These calls are just copying the input to the output byte by byte.
There is no need to worry about UTF-8 or not, as the output is just an
exact copy of the input

toke.c: Remove some NATIVE_TO_NEED calls

I believe NATIVE_TO_NEED is defective, and will remove it in a future
commit.  But, just in case I'm wrong, I'm doing it in small steps so
bisects will show the culprit.  This removes the calls to it where the
parameter is clearly invariant under UTF-8 and UTF-EBCDIC, and so the
result can't be other than just the parameter.

toke.c: Emphasize that only [A-Za-z] is used here

This code is attempting to deal with the problem of holes in the ranges
a-z and A-Z in EBCDIC.  By using macros with the suffix "_A", we
emphasize that.

Use real illegal UTF-8 byte

The code here was wrong in assuming that \xFF is not legal in UTF-8
encoded strings.  It currently doesn't work due to a bug, but that may
eventually be fixed: [perl #116867].  The comments are also wrong that
all bytes are legal in UTF-EBCDIC.

It turns out that in well-formed UTF-8, the bytes C0 and C1 never appear
(C2, C3, and C4 as well in UTF-EBCDIC), as they would be the start byte
of an illegal overlong sequence.

This creates a #define for an illegal byte using one of the real illegal
ones, and changes the code to use that.

No test is included due to #116867.

toke.c: Remove remapping for EBCDIC for octal

The code prior to this commit converted something like \04 into its
EBCDIC equivalent only in double-quoted strings.  This was not done in
patterns, and so gave inconsistent results.  The correct thing to do
should be to do the native thing, what someone who works on a platform
would think \04 do.  Platform independent characters are available
through \N{}, either by name or by U+XXXX.

The comment changed by this was wrong, as in some cases it was native,
and in some cases Unicode.

Remove EBCDIC remappings

Now that the Unicode tables are stored in native format, we shouldn't be
doing remapping.

Note that this assumes that the Latin1 casing tables are stored in
native order; not all of this has been done yet.

Add and use macro to return EBCDIC

The conversion from UTF-8 to code point should generally be to the
native code point.  This adds a macro to do that, and converts the
core calls to the existing macro to use the new one instead.  The old
macro is retained for possible backwards compatibility, though it
probably should be deprecated.

charnames: Make work in EBCDIC

Now that mktables generates native tables, we need to make U+XXXX mean
Unicode instead of native.

Unicode::UCD: Work on non-ASCII platforms

Now that mktables generates native tables, it is a fairly simple matter
to get Unicode::UCD to work on those platforms.

mktables: Generate native code-point tables

The output tables for mktables are now in the platform's native
character set.  This means there is no change for ASCII platforms, but
is a change for EBCDIC ones.

Code that didn't realize there was a potential difference between EBCDIC
and non-EBCDIC platforms will now start to work; code that tried to do
the right thing under these circumstances will no longer work.  Fixing
that comes in later commits.

mktables: Move table creation code

This code is moved later in the process.  This is in preparation for
mktables generating tables in the native character set.  By moving it to
later, the translation to native has already been done, and special
coding need not be done.

This also caught 7 code points that were omitted somehow in the previous
logic

Fix some EBCDIC problems

These spots have native code points, so should be using the macros for
native code points, instead of Unicode ones; this also changes to use
the portable symbolic name of a code point instead of the non-portable
hex.

Remove unnecessary temp variable in converting to UTF-8

These areas of code included a temporary that is unnecessary.

utf8.h: Correct macros for EBCDIC

These macros were incorrect for EBCDIC.  The 3 step process given in
utfebcdic.h wasn't being followed.

Extract common code to an inline function

This fairly short paradigm is repeated in several places; a later commit
will improve it.

Don't use EBCDIC macro for a C language escape

C recognizes '\a' (for BEL); just use that instead of a look-up.

regen/unicode_constants.pl could be used to generate the character for
the ESC (set in nearby code), but I didn't do that because of
potential bootstrapping problems when porting to an EBCDIC platform
without a working perl.  (The other characters generated in that .pl are
less likely to cause problems when compiling perl.)

Use byte domain EBCDIC/LATIN1 macro where appropriate

The macros like NATIVE_TO_UNI will work on EBCDIC, but operate on the
whole Unicode range.  In the locations affected by this commit, it is
known that the domain is limited to a single byte, so the simpler ones
whose names contain LATIN1 may be used.

On ASCII platforms, all the macros are null, so there is no effective
change.

Use new clearer named #defines

This converts several areas of code to use the more clearly named macros
introduced in the previous commit

utf8.h, utfebcdic.h: Create less confusing #defines

This commit creates macros whose names mean something to me, and which I
don't find confusing.  The older names are retained for backwards
compatibility.  Future commits will fix bugs I introduced from
misunderstanding the meaning of the older names.

The older names are now #defined in terms of the newer ones, and moved
so that they are only defined once, valid for both ASCII and EBCDIC
platforms.

pp_ctl.c: Use isCNTRL instead of hard-coded mask

This is clearer and portable to EBCDIC.

There is a subtle difference in the behavior here, which I believe is a
bug fix.  Before, the code didn't treat DEL as a control, and now it
does.

utf8.c: is_utf8_char_slow() should use native length

What is passed is the actual length of the native utf8 character.  What
this was calculating was the length it would be if it were a Unicode
character, and then compared, apples to oranges.

Stop t/op/coreamp.t leaving temporary files behind

test.pl will delete any file made by tempfile(), but it won't delete the
*.dir and *.pag files made by dbmopen. Hopefully this is the right way to
delete them, cribbed from lib/AnyDBM_File.t.

Stop t/io/utf8.t leaving a temporary file behind on Windows

Filehandles need to be closed for unlink to work on Windows.

Prevent ExtUtils-CBuilder leaving test output on Windows

The link function call in the have_compiler and have_cplusplus tests create
a compilet.def file on Windows which is correctly recorded for cleaning up
when the EU::CB object is destroyed, but if another one gets made in the
meantime then ExtUtils::Mksymlists::Mksymlists moves the first one to
compilet_def.old, which isn't recorded for cleaning up and gets left
behind when the test script has finished. Using a new object each time,
destroying the previous one first, prevents this.

Update the comments in t/op/magic.t

(This should have been part of the previous commit, but I forgot to --amend
it)

${^MPEN} had been treated as a synonym of ${^MATCH} due to a missing break;

A missing break; in Perl_gv_fetchpvn_flags() meant that the variable ${^MPEN}
had been behaving as a synonym of ${^MATCH}. Adding the break makes ${^MPEN}
behave like all other unused multi-character control character variable.

perldelta - Rewordings in the light of fa3234e35d

regen Configure after backports

os-types are sorted

perl5200delta: Mention broken modules from #119463

inline.h: Avoid redundant ckWARN call

ckWARN calls Perl_ckwarn.  So does Perl_ck_warner.  So there is no
need to use both.

perldiag: Reword/rewrap embedded null warning

‘syscall arguments’ implies arguments to the syscall() function,
which is not the case here.  Also reword the rest to sound better
in English.

perlpacktut: mention h2ph

Mentioning syscall.ph without saying how to get it is not
as helpful as it could be.

Increase $XS::APItest::VERSION to 0.56

Make vivify_defelem allow &PL_sv_undef array entries

This is something I failed to change in commit ce0d59f.  I don’t know
of a way to trigger this in pure-Perl code, hence the use of XS in
the test.  It did show up in pure-Perl code due to a bug fixed by the
previous commit.

Stop creating defelems for undef in foreach(@_)

This is part of ticket #119433.  This particular bug is triggered by
Data::Dump’s test suite.

Commit ce0d59f changed arrays to use NULL for nonexistent elements,
instead of &PL_sv_undef (the special scalar returned by Perl’s ‘undef’
operator).

‘foreach’ was not updated to account.  It was still treating
&PL_sv_undef as a nonexistent element.  This was causing ‘Modifica-
tion of non-creatable array value attempted, subscript 0’, due to a
similar bug in vivify_defelem, which the next commit will fix.

(Fixing vivify_defelem without fixing foreach will make the test pass,
but for foreach to create a defelem to begin with is inefficient and
should be addressed anyway.)

perldelta: typo

rmg: provide a link to edit-a-ticket page to check versions

perlhist: 5.17.11 was missing!

perldelta - Fill in descriptions of module upgrades and new tests

Move the thrice-repeated "64bitint is buggy?" test from hints to Configure.

OpenBSD and its two* forks each have the same "is 64 bit int support buggy?"
test code as a callback unit duplicated in their hints files. As the code is
portable C, there seems to be no harm in moving it to Configure, and running
the test on all platforms. This reduces code duplication, and will reduce it
further if another OpenBSD fork appears.

* This week.

Only predeclare S_sv_or_pv_pos_u2b for -DPERL_CORE or -DPERL_EXT

Otherwise when compiling XS code, there is a declaration for a function
which is never used, which can cause some compilers to issue a warning.

mg.h: Suppress compiler warning

GCC says:
pp_hot.c: In function 'Perl_pp_match':
pp_hot.c:1453: warning: signed and unsigned type in conditional expression

B::INVLIST isa B::PV (for now)

If the compiler stumbles over a B::INVLIST treat it as B::PV
and do not error.
Also restore rudimentary B versioning support for BIND and INVLIST.