IRIX long-double sqrt(2) one bit error in the least significant end.

IRIX cc -c99 does -D__c99 but none of the other C99 macros.

Admittedly this change could make C99-ness visible also
on platforms beyond IRIX, but that should be a good thing.

IRIX long double: use the C99/C11-style generic math macros.

Without this the IRIX libmath _isinfl/_isnanl APIs are not used,
and the explicit comparison against NV_MAX/-NV_MAX is used instead,
which seems to work, but is definitely ickier and probably slower.

In the ideal world we could have a Configure test for these math macros.

perldelta copy-editing

Clean-up temporary directories in Module-Metadata tests

Already merged upstream, and no version bump required for this test-only
module.

reimplement $^WIN32_SLOPPY_STAT as a magic var

The original implementation in commit cba61fe146 was sloppy. It is named
like a special var, it is listed as a special var, but it was a regular GV.
Since nobody knows this var exists, and full stat is the default (which I
disagree with see below). There will be alot more PP and C/XS perl stat()
calls (atleast a couple to dozens or low 100s for short lived perl
processes) than reads/writes to this global scalar (rounded to 0 R/Ws)
in a Win32 perl process. So avoid the 1 usually failing GV package (hash)
lookup for each PP/XS/PL C stat by using magic vars and a C bool. This is
a perf increase. Use sv_true instead of SvTRUE_NN because this code is
extremely rare to execute and the macro has large machine code.

I disagree with the default being full stat with since this increases the
number of kernel IO calls and ASCII->UTF16 conversions, and there was
perf criticism in the original thread that implemented this
this http://www.nntp.perl.org/group/perl.perl5.porters/2006/02/msg109917.html
but why full stat is default is for another ticket. This patch lessens the
overhead of full stat until something else is decided.

Change the initial value of the sloppystat setting for miniperl to be true
instead of doing it in buildcustomize.pl in PP. Revert part of
commit 8ce7a7e8b0 "speed up miniperl require on Win32" to acomplish this.
Unlike Unix perl, no object files are shared between mini and full perl,
so changing the default is fine on Win32 Perl. If minitest/miniperl really
need hard link testing/support, they can explictly turn off sloppy stat
and enable full stat with the special var. Changing the stat default from
C for miniperl avoids creating the special GV on each miniperl process
start as it previously was with the buildcustomize.pl way.

Changing stat setting in C and not PP also saves a couple IO calls in
win32_stat when opening the first .pl if it isn't -e, and
opening buildcustomize.pl in all permutations. The PP code in S_parse_body
contains a -f. See ticket for this patch for details.

Only CPAN use of this special var is
File-Stat-Moose-0.06/lib/File/Stat/Moose.pm#L208  according to cpangrep.

Make IO::Poll->poll call _poll even with an empty fd array

Now that _poll() properly handles an empty array, this fixes
[rt.cpan.org #25049].  The commit referenced in that ticket never made
it to CPAN nor blead.

Fix assertion when calling IO::Poll::_poll() with an empty fd array

  perl: IO.xs:322: XS_IO__Poll__poll: Assertion
  `PL_valid_types_PVX[((svtype)((_svpvx)->sv_flags & 0xff)) & 0xf]'
  failed.

This is because NEWSV(…, 0) returns undef, with a grabage pointer in
the PV slot.  This doesn't seem to matter in practice, since nothing
actually dereferences the pointer when nfds is zero, but to be safe we
should pass in _some_ valid pointer, so just use the SV* itself;

remove extra stat() call from .pm opening+remove extra safepath check

Originally S_doopen_pm had 2 stat calls, one on the .pm path, and another
on the .pmc, to get mtimes of both. Commit a91233bf4c "Load .pmc always,
even if they are older than a matching .pm file." (see
http://www.nntp.perl.org/group/perl.perl5.porters/2006/03/msg110639.html )
got rid of one of the stat calls but the other was left in place, possibly
as an oversight. S_check_type_and_open itself does another stat call on
unix to check for bad kinds of FS entries (reading a dir as a file), so
assuming someone used .pmc files, a good .pmc would be stat, stat,
open instead of the ideal, stat, open. Remove the extra stat from
S_doopen_pm for efficiency. Since the timestamp compare was removed, the
role of S_doopen_pm has been to verify an attempted path is acceptable to
pass to the FS (no IO done), and generate a .pmc path (no IO done), the
IO side of thing is in S_check_type_and_open, it shouldn't be in
S_doopen_pm.

On Win32, on a no .pmc build, an open is directly done on the attempted
.pm path for efficiency, no stat is done normally (see commit d345f48775
"Win32: stat() only after a failed open() on a module"). Before this patch
the .pmc attempted path got a stat which on Win32 is more than 1 IO call,
compared to Win32 open which is 1 IO call. With this patch, the Win32
specific IO logic in S_check_type_and_open executes instead of a generic
Win32 stat so there is just 1 failing IO call for file not found (typical
case for .pmc) instead of multiple file not found IO calls. See ticket for
details.

When .pmc files are enabled (enabled is default), 2 checks for bad null
char paths were done, once in S_doopen_pm, then again in lower level
S_check_type_and_open. Do the check only once in the higher level call
(S_doopen_pm) for efficiency, there is no way for string "c" which is
catted on to contain a null. There was an existing comment refering to
the problem of a low level check for null returning a message about a
".pmc" instead of a ".pm", so that is another reason to do it at a higher
level. Note on no PMC builds, S_check_type_and_open replaces S_doopen_pm
and still must do the check.

For IRIX the official symbol is __sgi, not __irix__.

The __sgi is defined both by SGI cc and gcc.

The change does not seem to change the set of failures with
uselongdouble build; there are two known ones in general
[perl #125298] (warnings) and [cpan #105030] (Time::Piece %z),
and then for uselongdouble a bunch of infnan and locale failures
that I haven't gotten around to reporting or fixing.

some perldelta entries

for

    6768377 make EXTEND() and stack_grow() safe(r)
    052a7c7 fix up EXTEND() callers

and a missed one (my fault) from 5.23.2:

    a5f4850 re-implement OPpASSIGN_COMMON mechanism

optimise save/restore of PL_delaymagic.

A few places (pp_push, pp_unshift, pp_aassign) have to
set PL_delaymagic on entry, and restore it on exit. These are hot
pieces of code. Rather than using  ENTER/SAVEI16(PL_delaymagic)/LEAVE,
add an extra field to the jumpenv struct, and make the JUMPENV_PUSH / POP
macros automatically save and restore this var.

This means that pp_push etc only need to do a local save:

    U16 old_delaymagic = PL_delaymagic;
    PL_delaymagic = DM_DELAY;
    ....
    PL_delaymagic = old_delaymagic;

and in case of an exception being raised, PL_delaymagic still gets
restored.

This transfers the cost of saving PL_delaymagic from each call to
pp_aassign etc to each time a new run level is invoked. The latter should
be much less frequent.

Note that prior to this commit, pp_aassign wasn't actually saving and
restoring PL_delaymagic; it was just setting it to 0 at the end. So this
commit also makes pp_aassign safe against PL_delaymagic re-entrancy like
pp_push and pp_unshift already were.

Delay @ISA magic while unshifting

pp_unshift() first calls av_unshift(), which prepends the the
requisite number of undefs, then calls av_store() for each item.
However, unlike pp_push() it was not setting PL_delaymagic around the
av_store() loop, so when unshifting onto @ISA, its magic would be
triggered while there were still undefs in the array, causig the
following spurious warning:

    $ perl -wE 'package Foo; unshift @ISA, qw(A B)'
    Use of uninitialized value in unshift at -e line 1.

Also fix pp_push() to save and restore PL_delaymagic instead of
clearing it, so that e.g. unshifting a tied value with FETCH pushing
onto another @ISA doesn't erroneously clear the value from underneath
the unshift.

rt.perl.org #123977 - clear errno in IRIX PERLIO=stdio

Under some circumstances IRIX stdio fgetc() and fread() set the errno
to ENOENT, which makes no sense according to either IRIX or POSIX docs.
Just clear such an errno.

Book-keeping for the previous commit (which restored the VC6 build, btw)

Win32 inet_pton fallback misc fixes

-VC complains in inet_pton
 "warning C4715: 'inet_pton' : not all control paths return a value"
 this isn't much a problem since Socket.xs doesn't allow anything but
 AF_INET and AF_INET6 on a XSUB level but fix the implementation anyway
 since the previous cargo culted off the internet version has flaws, so
 the Socket.xs version is usable elsewhere if necessery
-remove copying the string to C auto array, unix inet_ptoa requires null
 terminated strings, so does WSAStringToAddress. WSAStringToAddress's docs
 dont mention a maximum length to the input string, so no reason to
 truncate and re-null terminate it
-MSDN's docs for WSAStringToAddress mentions that filling in sin_family
 is required, even though lpAddress is an output arg, not input and a
 duplicate of arg AddressFamily, there is probably some legacy protocol
 driver out in the world that requires this
-static the functions, these fallbacks dont need to be visible in any other
 .o, and with static they might be inlined/further optimized
-provide fallbacks for Visual C 6 (circa 1998) with very old headers that
 were created before RFC 2553 was created

Replace 2 strcat()s with strlen() and memcpy() in dl_dlopen.xs.

In the #if defined(DLOPEN_WONT_DO_RELATIVE_PATHS) block, there were two uses
of strcat() that that the OpenBSD linker spotted and grumbled about.

It can't see that the code was clear enough to be "obviously no bugs".
However, I can see that with 2 successive calls to strcat() there's one more
O(1) scan of the string length than there needs to be. So refactoring to
eliminate strcat() also removes avoidable inefficiencies.

Fortunately, this code isn't in a block that the MS compiler will ever see.
So it won't be suggesting that memcpy_s() is obviously more secure than
memcpy() (because two lengths are better than one).

rt.perl.org perl #88814 was revived in openbsd by commit 23705063.

openbsd pre-5.2 + threads + signals is broken,
and 23705063 made threads the default.

Similar case to 8e7f1f72.

perl #126306: openbsd t/io/errno.t tests fail randomly

perl #71504 added the skip for openbsd+threads+stdio;
then commit 23705063 made -lpthread the default,
necessitating the skip even without threads.

Add the OS X processor support.

OS X versioning dance.

Note the difference between the OS X version (10.X) and the kernel version,
it's the latter that Configure knows as $osvers.  Adding a cross-reference
table for these versions rom the NetBSD project.

For OS X 10.6 or above, do not any more use the MACOSX_DEPLOYMENT_TARGET,
the toolchains should work fine without.  Until now the deployment target
was hardwired to 10.3.  This logic comes from
https://rt.perl.org/Public/Bug/Display.html?id=117433

For OS X releases from 10.3 until 10.5, no change, still using
the MACOSX_DEPLOYMENT_TARGET=10.3 for linking.

For OS X releases before 10.3, no change, still not using
the MACOSX_DEPLOYMENT_TARGET=10.3.

New: always add -mmacosx-version-min to ccflags and ldflags from
the env var $MACOSX_DEPLOYMENT_TARGET, if set.  If the var is not set,
set the min from the OS X version, from sw_vers(1).  Setting the var
should become handy for people building and packaging Perl for earlier
OS X versions.

We assume that the toolchain/SDK installed to system will be able to build
for the requested minimum versions and deployment targets, or if it is not,
it should properly warn or die.

Some related tickets, past and present:

https://rt.perl.org/Public/Bug/Display.html?id=126360
https://rt.perl.org/Public/Bug/Display.html?id=123985
https://rt.perl.org/Public/Bug/Display.html?id=123831
https://rt.perl.org/Public/Bug/Display.html?id=117433

rt.perl.org 126152 compile error after re-running Configure since AmigaOS merge

Configure /proc issues, honor d_procselfexe and procselfexe hints.

Note some files missing from blead in two upstream => blead distributions

Try to avoid doubling the cppflags if rerun without removing config.sh

This bug has been here since 2001, introduced by yours truly
in 58e77565.  Hasn't been too harmful, obviously.  It doubles
the cppflags only once, thankfully, unlimited doubling would
probably have been noticed earlier.

The avoidance maneuver is far from fool-proof.  To be more
fooler-proofer, some sort of order-preserving deduping would
be needed.

IRIX <sys/prctl.h> is not what Configure expects.

It exists, but the API is something completely different,
so the compilation attempt ends up in a fireworks display.

VMS-specific statbuf in Perl_find_script.

In 97466d2cbf895b I added a declaration at function scope, but in
some paths that was overridden at an inner scope, leaving the
function-level one declared but not used.  So lets go back to the
original intent of 45a23732c73c8 and have a separate declaration
in each block that needs it.

Revert "Missed one statbuf declaration in 45a23732c73."

This reverts commit 97466d2cbf895b35ac41b8bf7c31db955b52d48e.

Adding a declaration at function scope causes unused variable
warnings when there are paths that redeclare it at an inner scope.

Upgrade bignum from version 0.40 to 0.41

Move bignum from dist/ to cpan/

Also, blead is actually in sync with 0.40, not 0.37.

Upgrade Math::BigInt::FastCalc from 0.31 to 0.34

This removes the minor blead customizations: I couldn't see any sign of
them having been deliberately added to blead. They looked more like
differences that cropped up because CPAN changes hadn't all been imported
into blead.

Upgrade Math::BigInt from 1.999701 to 1.999704

This removes the minor blead customizations: I couldn't see any sign of
them having been deliberately added to blead. They looked more like
differences that cropped up because CPAN changes hadn't all been imported
into blead.

ext/XS-APItest/t/hash.t: Fix for EBCDIC

The .xs file was returning malformed UTF-8 due to not accounting for
length differences when substituting one code point for another.  It
just so happened that the code points chosen to be tested were the same
length as the substituted ones on ASCII platforms, but not EBCDIC

And the .t is changed to convert Unicode code points to native

DynaLoader.t: Skip test on z/OS

See thread beginning at
http://nntp.perl.org/group/perl.perl5.porters/231613

dl_findfile() does not find z/OS hospitable.

Math-BigRat is (nearly) in sync with 0.260801

Math-BigInt-FastCalc has a slightly customized .pm file

Not sure if these customizations are required; just noting them here
for now.

Math-BigInt is (nearly) in sync with 1.999701

Socket.pm is customized (for the ++$VERSION) as well as Socket.xs

Module-Metadata-1.000029-TRIAL is in blead

Correct the paths in the Encode customizations

Blead doesn't actually need these trivial customizations but they can't
be corrected without needing to bump the corresponding .pm file $VERSIONs
otherwise porting/cmp_version.t will fail since the customized versions
have already escaped in the last blead release. There is no sense in
adding customizations for the .pm files just to remove these
customizations, so they will have to stay for now.

Compress-Raw-Bzip2-2.069 has two more excluded files than were listed

Makefile: add TAGS target (etags, not ctags)

make -s: silent means silent

check MAKEFLAGS for -s|--silent|--quiet and honor it

[perl #126242] make the constant hash seeds unsigned char *

...to prevent warnings on most C compilers and build failures on C++
compilers for -DNO_HASH_SEED builds.

fix NO_HASH_SEED build

commit b1300a738f added PERL_HASH_FUNC_ONE_AT_A_TIME_HARD algo, which was
the first one to introduce 8 byte seeds, previously all the algos used 4
or 16 byte seeds. No case was added to the CPP tree for 8 byte const
seeds, so add one now. Otherwise the #error at the end of the tree runs
and breaks the build. NO_HASH_SEED define was public API in the past and
could be considered to still be public API, see commit f36626324a.
My use for NO_HASH_SEED is reducing entropy for tracking down memory
corruption.

PATCH: [perl #126180] /(?[\ &!])/ segfaults

qr/\p{pkg1::...foo}/ must be a user-defined property

So, if it isn't found and 'foo' doesn't begin with 'In' or 'Is', we know
that there would be a run-time error, which we can fail with at
compile time instead.  We use a different error message than if we don't
know if it is a user-defined property.

See thread beginning at
http://nntp.perl.org/group/perl.perl5.porters/231658

I didn't make a perldelta entry, as I doubt that this has ever come up
in the field, as I discovered the issue myself while playing around
investigating other bugs.

regcomp.c: Add macro to output diagnostic

This is like a similar macro, but takes an extra argument.  It will be
used in the next commit

regcomp.c: White-space, comments only

perldiag: Remove no-longer used message.

I noticed that this message was there, but hasn't been used for some
time, having been replaced, and I didn't look too hard for when.

podcheck.t: Regen db after recent new long verbatim line

Commit 6fc2106e6704b632dc6ea04410ea89e1fa4ca43c added a verbatim line
longer than 79 chars.

porting/maintainers.t: Skip if -DPERL_EXTERNAL_GLOB

Maintainers requires the internal File::Glob.

I also reordered the skip if VMS test so the skip tests are all adjacent.

Fix \p followed by a non-alpha

See threads beginning at
    http://nntp.perl.org/group/perl.perl5.porters/231263
    http://nntp.perl.org/group/perl.perl5.porters/231389

Prior to this commit, these did not generate the pattern that would be
expected, and displayed apparently irrelevant warnings.  Now this is a
fatal error.

This resolves [perl #126187].  I don't think it's worth a perldelta
entry for this ticket, as the new error message is now in perldelta, and
this never worked properly anyway; it's just now we have a proper error
message.  Patches welcome if you disagree.

regcomp.c: Make compile and run-time error msgs identical

Prior to this commit, an unknown Unicode property gave different
messages depending on when the problem was found.  Prior to the previous
commit, most were found at run-time, but now most are found at
compile-time.  Therefore use the runtime message everywhere, as it was
the most often encountered before.

regcomp.c: Find more errors at compile time

Users can create their own Unicode-like properties, but the names of
those must follow a very restricted syntax.  When compiling a property,
if we can't find it, we have presumed it might be a user-defined one
that will be known at runtime.  But if the name doesn't follow the
restricted syntax, it can't be such, and so must be an error.  Abort now
rather than waiting until run time.

Upgrade Unicode::Normalize from version 1.19 to 1.21

Upgrade File::Path from version 2.11 to 2.12

Upgrade ExtUtils::CBuilder from version 0.280223 to 0.280224

Upgrade experimental from version 0.015 to 0.016

[perl #126229] POSIX::strerror() clears $!

If POSIX::strerror is passed $! as its arg, then it ends up doing
local $! = $!, which due to a bug in the localisation system, leaves $!
undef even after scope exit.

Work around the bug by assigning $_[0] to a my var first.

make /fixed-substr/ much faster.

TL;DR: on platforms with a libc memchr() implementation which makes good
use of underlying hardware support, patterns which include fixed
substrings will now often be much faster; for example with glibc on on a
recent x86_64 CPU, this:

    $s = "a" x 1000 . "wxyz";
    $s =~ /wxyz/ for 1..30000

is now about 7 times faster. On systems with slow memchr(), e.g. 32-bit
ARM Raspberry Pi, there will be a small or little speedup. Conversely,
some pathological cases, such as "ab" x 1000 =~ /aa/ will be slower now;
up to 3 times slower on the rPi, 1.5x slower on x86_64.

In detail:

The perl core includes a Boyer-Moore substring matcher, Perl_fbm_instr(),
which is used to quickly find a fixed substring within a longer string,
where a table of lookups is pre-computed from the substring. As well as
being used in index() when the substring is a constant, its main use
is in patterns. When the regex engine compiles a pattern, it typically
takes note of the two longest fixed substrings within the pattern; for
example in

    /[01]abc\w+de\d+fghij+/

the two longest are "abc" and "fghij". The engine uses Perl_fbm_instr() to
scan for these two strings before running the full NFA. This often allows
the string to be quickly rejected, or to find a suitable minimum starting
point to run the NFA.

However, Perl_fbm_instr() was written about 16 years ago and has been
virtually untouched since, so it could do with some love.

It currently special-cases strings of length 1 and 2, using roll-your-own
loops along the lines of

    while (s < end) { if (*s++ = c1) ... }

while strings of length 3+ use the Boyer-Moore algorithm. The big
advantage of BM is that in a best-case, where none of the characters from
the substring are found in this region of the string, it only has to test
every N'th char, where N is length of the substring. For example when
searching for wxyz in abcdefghikl..., it just reads and tests d,h,l,..

However these days some platforms have decent memchr() implementations.
For example, glibc has assembly-level implementations for i386, x86_64,
sparc32/64, powerpc32/64, s390-32/64, arm, m68k and ia64 by the looks of
it. These can often be substantially faster than a C-level implementation.

This commit makes Perl_fbm_instr() use memchr() where possible.

For the length == 1 special case, it just calls memchr() directly rather
than using a loop as previously.

For the length == 2 special case, it continues to distinguish the cases
where the two chars of the substring are the same or differ. For the
former it calls memchr() after an initial direct failure, i.e.

    if (*s != c) { s++; s = memchr(....); ... }

For the latter case it does a similar direct test first (to avoid the
costly overhead of a call to memchr() when the next char is the one we
seek anyway), but in addition, on each failure to find the second char
following a found first char, it swaps which char it's searching for.
This means that in something like "aaaaaaa..." =~ /ab/, it wont keep
hopping 1 char position with memchar(s,'a'); after the first hop it
will do memchr(s,'b') and skip lots of chars in one go. This helps reduce
the number of pathological cases.

For the length >= 3 cases (normal BM), it keeps using BM, but after each
iteration where the pointer has been incremented by the skip determined by
the BM algorithm, it now does an additional

    if (*s != c) { s++; s = memchr(....); ... }

step before running the next iteration of BM.

fbm_instr(): tweak docs and formatting

Expand the commentary at the start of this function; add more blank lines
to separate chunks of code, and document what SVpbm_TAIL is for.

Perl_call_sv move EXTEND into branch that needs it

If we aren't manipulating the stack, dont fetch it, check and possibly
extend it. There is a slight chance this EXTEND was covering up missing
EXTENDs somewhere else in Perl core or CPAN C code, if future bisects or
valgrind reports show that this EXTEND by 1 must always be done, this
patch can be reverted. pp_method_named contains a EXTEND/XPUSH* call,
pp_entersub requires 1 arg on stack so, both sides of the
"if (!(flags & G_METHOD_NAMED))" test will in theory make sure there is
1 free slot on the stack on entry to a SUB or XSUB.

See also
http://www.nntp.perl.org/group/perl.perl5.porters/2015/09/msg231329.html

remove repeated PL_stack_sp derefs in Perl_eval_sv/Perl_call_sv

Reduce scope of local SP and remove excessive reads and writes to
PL_stack_sp in Perl_eval_sv/Perl_call_sv. EXTEND macro refetches the
possibly realloced SP on its own, Perl_stack_grow returns the new SP as a
retval and therefore in a register. By using PL_stack_sp instead of
Perl_stack_grow, an extra redundant mem read is done. Also dont keep
SP around for long periods unused, it wastes a C stack slot or non-vol
reg and makes the callframe bigger. The EXTEND could be placed
in the !(flags & G_METHOD_NAMED) branch, but that will be done in another
patch for bisectability.

VC 2003 -O1 machine code sizes of the functions
Perl_eval_sv before 0x28a after 0x286
Perl_call_sv before 0x3cd after 0x3cb

The savings look small since in x86 "*var+=4" and "var+=4" are the same
number of bytes to encode the instruction, only the mod R/M bitfield vals
are different. RISC CPUs benefit more from this patch.

commit c106c2be8b "G_METHOD_NAMED flag for call_method and call_sv"
added skipping the push SV onto stack

The EXTEND and PL_stack_sp direct manipulation code is from
commit a0d0e21ea6 "perl 5.000". The reason is unknown why it did
"SV** sp = stack_sp;" and later "EXTEND(stack_sp, 1);" instead of using
SP, since EXTEND at that time, and to this day requires C auto sp be in
scope.

perldelta for 0f948285b1d2

Include the name of the non-lvalue sub in error message

This makes the cause of the error more obvious if you accidentally call
a non-lvalue sub in the final position of an lvalue one.

[perl #126051] make the warnings::enabled example use warnings::enabled

7e6d00f88633 added the warnif() function and changed most uses of
warnings:enabled() to use warnif(), including this one.  Revert
just that part.

sync regen/warnings.pl and warnings.pm $VERSION

regen/warnings.pl's $VERSION was at 1.04 despite it being modified
each time warnings.pm is modified.

So make them use the same version number.

add Win32 USE_NO_REGISTRY build option

-the first arg of win32_get_privlib is not used if the registry is not
 queried, create a macro to allow the arg to drop out on WIN32_NO_REGISTRY
 builds for efficiency and not to have unused C litteral strings in the
 binary
-This patch changes the ABI of
 PerlEnv_lib_path/PerlEnvLibPath/win32_get_privlib between USE_NO_REGISTRY
 and no USE_NO_REGISTRY. Since win32_get_privlib is not exported from
 perl523.dll, assume it and PerlEnv_lib_path are not public API, note
 technically PerlEnv_lib_path will be callable only on PERL_IMPLICIT_SYS
 builds, on no PERL_IMPLICIT_SYS builds it will fail at link time since
 win32_get_privlib isnt exported. Therefore place it in
 non-[affecting]-binary compatibility even though it does affect binary
 compatibility.
-delay load advapi32.dll to save startup time (loading the DLL and the DLL
 calling its initializers in DllMain) and one 4 KB memory page for
 advapi32's .data section (doing "perl -E"sleep 100" on WinXP shows
 advapi32 has a 20KB long .data section, first 4 KB are unique to the
 process, the remaining 16KB are COW shared between processes according
 to vmmap tool), putting a DebugBreak() in pp_getlogin and doing a
 "nmake all" shows miniperl never calls getlogin during the build process.
 An nmake test shows only ext/POSIX/t/wrappers.t and lib/warnings.t execute
 pp_getlogin. Keeping advapi32.dll out of the perl process requires
 removing comctl32.dll, since comctrl32.dll loads advapi32.dll, from perl
 which I always do as a custom patch.

filed as [perl #123658]

XXXXXXXXXXXXXXXXXXXXXXX

stop checking the Win32 registry if *"/Software/Perl" doesn't exist

This stops each ENV var lookup (and 16 calls to get_regstr, most of which
are %ENV lookups, are done automatically each time a Win32 Perl process
starts) from querying the registry for usually failing lookups.
ActiveState is the only known major user of the Software/Perl reg key.

details:
-cache the root handles, so a typically failing env var lookup does only 1
 system call instead of 3 if the parent key exists
-if the key exists, looking it up is slightly faster since it is 4
 registry syscall instead of previously 6 (open "*\Software\Perl", 2
 RegQueryValueExAs(on "found" behavior each RegQueryValueExA does 2
 RegQueryValueExW  calls), close "*\Software\Perl")
-dont make a system call to lookup a value if the parent key doesn't exist
-change "Software\\Perl" to "SOFTWARE\\Perl" since the reg is case
 preserving but lookups are not case sensitive, this all caps casing is
 what regedit shows, and might save a couple cpu cycles in the DB lookup
 in the kernel
-use RegOpenKeyExW instead of RegOpenKeyEx (actually RegOpenKeyExA), this
 avoids ansi to utf16 conversions at runtime
-dont check HKEY handles for NULL before calling RegCloseKey.
 MS and ReactOS RegCloseKey checks for NULL (zero) handle first thing and
 returns ERROR_INVALID_HANDLE as the retval of RegCloseKey. MS App Verifier
 does not complain about NULL handles.
-Dont check the retval of RegCloseKey, there is no way to dispatch an error
 at this point in the process, there are no interps, and no perlio, and
 maybe no console if its a GUI, and the process is probably exiting anyway.
 Calling Perl_noperl_die (no perl, no perlio, print to stderr) would not
 be friendly to an embedder. A crash box with RaiseException with
 EXCEPTION_INVALID_HANDLE is a bad UI.
-Dont bother to zero the HKEY handles, after a PERL_SYS_TERM until the
 next (if any) PERL_SYS_INIT3, libperl is in an undefined state, it is the
 embedders responsibility to refcount and serialize calls to
 PERL_SYS_INIT3/PERL_SYS_TERM if necessary

See details in [perl #123658]

regcomp.c: Fold only use of static function into its caller

regpatws() is only used in one place, and is dangerous to retain it as a
named entity.  This is because wherever white space is to be skipped,
(#...) comments are to be as well, so the function that does both things
should be called instead of this one.

regcomp.c: Remove useless code

Just above this code, the parse has moved to beyond /x white space and
comments.  There's no need to try moving again.

Allow (#...) anywhere white space is under qr//x

Wherever you can have white space under /x, you can also have a (#...)
comment (even without /x).  Prior to this commit, there were several
places that allowed the white space but not the comments.

This resolves [perl #116639].

Restrict white space inside [] inside(?[ ]) to \h

This experimental construct has turned on /x processing for any interior
bracketed character classes, except comments are not allowed.  But,
bracketed character classes have traditionally all been on one line, and
I'm leery of the problems that could arise if we extend them to
multiple.  Therefore, restrict the white space to just spaces and tabs
before this feature becomes non-experimental.  If there is cause, we can
later relax the prohibition.

regcomp.c: Simplify some handling

Prior to this commit the current parse pointer could be off-by-one from
what you might expect.  This keeps it at the beginning of a character
and asserts for that.

regcomp.c: Replace apparent dead code by an assert

In code reading, I concluded that this code path should never happen,
but added an assert() to be sure.

regcomp.c: Add some LIKELY(), UNLIKELY().

This is pretty easy to know which branches are likely.

regcomp.c: Replace apparent dead code by an assert

In code reading, I came to the conclusion that this is useless code,
but assert() to be sure.

regcomp.c: White-space only

Outdent some unneeded inner blocks

regcomp.c: Simplify some debug handling

This code seems to date from before the variable 'parse_start' was more
global in this routine.  Instead of defining a local variable which
masks the outer one, use the outer one with suitable offset adjustments.

In qr/[(? ... ])/, keep parse pointer at 1st char byte

When parsing an extended bracketed character class, pass 1 just blindly
increments the parse pointer by one byte, so that it can point to
interior bytes of a multi-byte character.  In pass 2, it takes more
care.  This works for pass1 as the size this construct always generates
an ANYOF node and so the size is known, and the only reason we are
parsing it is to find the end, and the only characters we care about are
UTF invariants.  But it is not so great practice to be pointing to the
middle of a character, and there may be consequences that I don't
foresee, so keep it pointed to character beginnings.

Fix some UTF-8 bugs in qr// compiling

Prior to this commit, nextchar() blindly advanced the parse by one byte,
and then looked to see if that starts a character that should be skipped.
But if the character being parsed is multi-byte, it's going to advance
to an interior byte, which is incorrect.  So change the code so it
advances across the whole current character. not just the first byte.

And several places in the code that wanted to advance the parse from the
current place to the end of any (#...) comments, or white space under
/x, would move the parse pointer back one byte, and call nextchar().
This sort of worked (but took up unnecessary cpu) as long as nextchar()
always advanced by exactly one byte.  But the previous paragraph showed
why this is wrong.  So change those calls to use the new function that
advances from where we are now, created in the previous commit.

I didn't come up with tests that consistently fail, but valgrind on
various .t files in the test suite shows bounds errors fixed by this
patch.

regcomp.c: Split function into two functions

Sometimes we want to move to the next non-ignored character in the
input.  The nextchar() function does that (but buggily in UTF-8).

And sometimes we are already at the next character, but if it is one
that should be ignored, we want to move to the first one that isn't.
This commit creates a function to do the second task by extracting the
code in nextchar() to it, and making nextchar() a lightweight wrapper
around it, and hence likely to be optimized out by the compiler.

This is a step in the direction of fixing the UTF-8 problems with
nextchar(), and fixing some other bugs.  The new function has added
generality which won't be used until a later commit.

regcomp.c: refactor a static function

nextchar() advances the parse to the next byte beyond any ignorable
bytes, returning the parse pointer before the advancement.

I find this confusing, as

    foo = nextchar();

reads as if foo should point to the next character, instead of the
character where the parse already is at.  This functionality is hard for
a reader to grok, even if the name weren't misleading, as the place the
variable gets set in the source is far away from the call.  It's clearer
to say

    foo = current;
    nextchar();

This has confused others as well, as in one place several commits have
been required to get it so it works properly, and games have been played
to back up the parse if it turns out it shouldn't have been advanced,
whereas it's better to check first, then advance if it is the right
thing to do.  Ready-Fire-Aim is not a best practice.

This commit makes nextchar() return void, and changes the few places
where the en-passant value was used.

The new scheme is still buggy, as nextchar() only advances a single
byte, which may be the wrong thing to do when the pattern is UTF-8
encoded.  More work is needed to be in a position to fix this.  We have
only gotten away with this so far because apparently no one is using
non-ASCII white space under /x, and our meta characters are all ASCII,
and there are likely other things that reposition things to a character
boundary before problems have arisen.

regcomp.c: Add a panic for code that shouldn't happen

It's better to quit than to blindly continue after failure.

regcomp.c: Fixes to comments

One of these is because the latest vim is not smart enough to know that
a '{' in a comment isn't part of the code for the purposes of the bounce
between start and end brace operation.  This is over a large quantity of
lines, so it is quite helpful for that to work.

utf8_heavy.pl: Clarify comment

if if is 0.0606 update Maintainers.pl, but only if if is

Fix 683e3b31e8b72cce

Found when backporting. JHI's reply:

Oops.

It should be define:define:define.

I was trying to stop the test that uses alarm() not to compiled in a
system where alarm() does not exist.

bump DynaLoader version to 1.35.

Missed one statbuf declaration in 45a23732c73.

The VMS-specific corner of the ifdef jungle ended up using
statbuf without declaring it, so add a declaration.

Constant data in .c, not in a .h

clang says:
./sdbm.h:54:20: warning: 'extern' variable has an initializer [-Wextern-initializer]

DynaLoader.doc was deleted 20 years ago in 3b35bae3

Trailing comma is non-standard.

(Found by cadvise, would have been found by gcc -pedantic.)

Since NUM_ANYOF_CODE_POINTS is 256, this_end is always < 256.

(And the %04X will not happen.)

(regcomp.h says that in theory NUM_ANYOF_CODE_POINTS can be more than 256.)

Coverity CID 104774

t/op/pack.t: Fix some skipped tests on EBCDIC

These tests were skipped on EBCDIC platforms because they failed there.
It turned out that the tests were ASCII-centric, and just had to be
modified slightly to pass.

t/op/pack.t: Clarify comment; change variable name

The variable is really the bytes that compose the utf8, not the utf8.
Make the name clearer.

partial PL_statbuf removal

Perl_nextargv has to have access to the Stat_t that is written to inside
S_openn_cleanup or else run/switches.t, io/argv.t, io/inplace.t, and
io/iprefix.t will fail. Removing the uses of PL_statbuf that are using
PL_statbuf due to historical reason, and not using PL_statbuf to pass data
between different funcs/different callstacks. This patch makes it easier to
remove PL_statbuf in the future since the number uses of it has been
reduced.

-in Perl_apply move SETERRNO before tot--; so the branch can be combined
 with other "tot--;" branches by CC optmizer
-combine 2 Perl_croak(aTHX_ "Illegal suidscript"); statements in
 S_validate_suid to make code look simpler, drop my_perl arg for space
 efficiency on threads of rarely executed code

Properly duplicate PerlIO::encoding objects

PerlIO::encoding objects are usually initialized by calling Perl methods,
essentially from the pushed() and getarg() callbacks. During cloning, the
PerlIO API will by default call these methods to initialize the duplicate
struct when the PerlIOBase parent struct is itself duplicated. This does
not behave so well because the perl interpreter is not ready to call
methods at this point, for the stacks are not set up yet.

The proper way to duplicate the PerlIO::encoding object is to call sv_dup()
on its members from the dup() PerlIO callback. So the only catch is to make
the getarg() and pushed() calls implied by the duplication of the underlying
PerlIOBase object aware that they are called during cloning, and make them
wait that the control flow returns to the dup() callback. Fortunately,
getarg() knows since its param argument is then non-null, and its return
value is passed immediately to pushed(), so it is enough to tag this
returned value with a custom magic so that pushed() can see it is being
called during cloning.

This fixes [RT #31923].

make sv_backoff tailcall friendly

Reorder the body of Perl_sv_backoff slightly to make it more tail-call
friendly, and change its signature from returning an int (always 0) to
void.

sv_backoff has only 1.5 function calls in it, there is a memcpy of a U32 *
for alignment reasons (I wont discuss U32_ALIGNMENT_REQUIRED) inside of
SvOOK_offset, and the explicit Move()/memmove. GCC and clang often inline
memcpy/memmove when the length is a constant and is small. Sometimes
a CC might also do unaligned memory reads if OS/CPU allows it
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20130513/174807.html
so I'll assume memcpy by short constant isn't a func call for discussion.
By moving SvFLAGS modification before the one and only func call, and
changing the return type to void, there is no code to execute after the
Move func call so the CC, if it wants (OS/ABI/CPU, specifically I am
thinking about x86-64) can tailcall jump to memmove. Also var sv can be
stored in a cheaper vol reg since it is not saved around any func calls
(SvFLAGS set was moved) assuming the memcpy by short constant was inlined.

The before machine code size of Perl_sv_backoff with VC 2003 -O1 was
0x6d bytes. After size is 0x61. .text section size of perl523.dll was
after was 0xD2733 bytes long, before was 0xD2743 bytes long. VC perl does
not inline memcpys by default.

In commit a0d0e21ea6 "perl 5.000" the return 0 was added. The int ret type
is from day 1 of sv_backoff function existing/day 1 of SV *s
from commit 79072805bf "perl 5.0 alpha 2". str_backoff didn't exist AFAIK,
only str_grow would retake the memory at the start of the block. Since
sv_backoff is usually used in a "&& func()" macro (SvOOK_off), it needed a
non void ret type, a simple ", 0" in the macro fixes that. All CCs optimize
and remove "if(0)" machine instructions so the ", 0" is optimized away in
the perl binary.

perlgit.pod: how to unescape 'git am' From lines

Due to Reasons, some UNIX mail systems escape any leading 'From ' lines
with a '>'. Explain how to un-escape them.