SAVEt_CLEARSV: only clear-in-place if RC==1

Currently it takes the 'clear-in-place' branch on lexical vars if
the ref count is <= 1. However, RC < 1 is a "should never happen"
condition, so rather than keeping that damaged var, take the other branch,
which will call SvREFCNT_dec() on it, which will Do the Right Thing
(like emitting a warning).

SAVEt_CLEARSV: handle SvOOK() specially

Add SVf_OOK to the list of flags that are handled in the 'slow' branch.
This allows us to avoid checking for hv_kill_backrefs() or sv_backoff()
for the majority of lexicals which won't require it.

SAVEt_CLEARSV: expand SvOK_off() macro

the next commit will change thinks that affect only part of the macro

SAVEt_CLEARSV: simplify SvREADONLY_off() condition

SAVEt_CLEARSV should always be called with SvPADMY() true, so don't test
for it, but assert it instead. Then change this:

    if (SvPADMY(sv) && !SvFAKE(sv))
         SvREADONLY_off(sv);

The SvPADMY() isn't needed, but we should test for RO-ness instead, to
avoid an unnecessary SvREADONLY_off().

SAVEt_CLEARSV: reindent after previous commit

whitespace-only changes

SAVEt_CLEARSV: check common flags

In the 'clear' branch of SAVEt_CLEARSV, there are several individual
if (SvSOMEFLAG(sv)) {...} tests. Wrap all these tests in a single
if (SvFLAGS(sv) & (union|of|all|flags)), so that for the common case
of boring lexicals that don't need special clear up, we can skip all the
individual tests

S_regmatch(): merge BOL and SBOL branches

The code body is the same for both of them.

copy xhv_rand and xhv_last_rand in threads clone

valgrind complains about these fields being uninitialised when cloned into a
new thread, because they aren't copied. It's fairly harmless, since these
fields are just used to perturb hash key iteration; but for completeness,
clone these fields too.

[perl #121230] fix kill -SIG on win32

v5.17.1-137-gc2fd40c tidied up perl's kill() implementation, making
-SIGNAME be handled correctly, It also eliminated the use of the killpg()
system/library call, which these days is usually just a thin wrapper over
kill(). By doing this, it assumed that the following are functionally
equivalent:

 killpg(pgrp, sig)
 kill(-pgrp, sig).

Unfortunately this broke Window's use of the (perl-level)

    kill negative_value, pid, ...

since under Windows, the killpg()/kill() identity doesn't hold
(win32_kill() uses negative ids for fake-PIds, not process groups).

Fix this by restoring the use of killpg() where available.

speed up (non)overloaded derefs

Consider a class that has some minimal overloading added - e.g. to give
pretty stringification of objects - but which *doesn't* overload
dereference methods such as '@[]'. '%[]' etc.

In this case, simple dereferencing, such as $obj->[0] or  $obj->{foo}
becomes much slower than if the object was blessed into a non-overloaded
class.

This is because every time a dereferencing is performed in pp_rv2av for
example, the "normal" code path has to go through the full checking of:

  * is the stash into which the referent is blessed overloaded? If so,
  * retrieve the overload magic from the stash;
  * check whether the overload method cache has been invalidated and if so
    rebuild it;
  * check whether we are in the scope of 'no overloading', and if so
    is the current method disabled in this scope?
  * Is there a '@{}' or whatever (or 'nomethod') method in the cache?
    If not, then process the ref as normal.

That's a lot of extra overhead to decide that an overloaded method doesn't
in fact need to be called.

This commit adds a new flag to the newish xhv_aux_flags field,
HvAUXf_NO_DEREF, which signals that the overloading of this stash
contains no deref (nor 'nomethod') overloaded methods. Thus a quick check
for this flag in the common case allows us to short-circuit all the above
checks except the first one.

Before this commit, a simple $obj->[0] was about 40-50% slower if the
class it was blessed into was overloaded (but didn't have deref methods);
after the commit, the slowdown is 0-10%. (These timings are very
approximate, given the vagaries of nano benchmarks.)

Document what the gv_check() function does

gv_check(): use aux flag rather than IsCOW

Currently the SVf_IsCOW flag doesn't have any meaning for HVs,
except that it is used in the specific case of gv_check() to temporarily
mark a stash as being scanned. Since stashes will have the HV_AUX fields,
we can use a flags bit in the new xhv_aux_flags field instead.

This then potentially frees up the SVf_IsCOW for use as a new general flag
bit for *all* HVs (including non-stash ones).

add aux_flags field to HVs with aux struct

Add an extra U32 general flags field to the xpvhv_aux struct (which is
used on HVs such as stashes, that need extra fields).

On 64-bit systems, this doesn't consume any extra space since there's
already an odd number of I32/U32 fields. On 32-bit systems it will consume
an  extra 4 bytes. But of course only on those hashes that have the aux
struct.

As well as providing extra flags in the AUX case, it will also allow
us to free up at least one general flag bit for HVs - see next commit.

make OP_AELEMFAST work with negative indices

Use aelemfast for literal index array access where the index is in the
range -128..127, rather than 0..255.

You'd expect something like $a[-1] or $a[-2] to be a lot more common than
$a[100] say. In fact a quick CPAN grep shows 66 distributions
matching /\$\w+\[\d{3,}\]/, but "at least" 1000 matching /\$\w+\[\-\d\]/.
And most of the former appear to be table initialisations.

[MERGE] optmise pp_entersub code

Do various bits of minor fiddling with the code of Perl_pp_entersub
to make the binary smaller and hopefully faster. All the usual stuff:
sprinkling LIKELY(), altering scope of vars etc.

All of this should make no functional difference, expect conceivably the
"SvPADTMP() not on IS_PADGV()" change (which also affects code outside
pp_entersub()).

This series of commits reduces the size of the pp_entersub object on gcc
x86_64 by about 11%, and shows no measurable change in performance (i.e.
noise dominates).

don't set SvPADTMP() on PADGV's

Under threaded builds, GVs for OPs are stored in the pad rather than
being directly attached to the op. For some reason, all such GV's were
getting the SvPADTMP flag set. There seems to be be no good reason for
this, and after skipping setting the flag, all tests still pass.

The advantage of not setting this flag is that there are quite a few
hot places in the code that do

    if (SvPADTMP(sv) && !IS_PADGV(sv)) {
        ...

I've replaced them all with

    if (SvPADTMP(sv)) {
        assert(!IS_PADGV(sv));
        ...

Since the IS_PADGV() macro expands to something quite heavyweight, this is
quite a saving: for example this commit reduces the size of pp_entersub by
111 bytes.

pp_entersub(): simplify XSUB arg cleanup code

The code that reduces the returned XS args to 1 arg in scalar context
was a bit messy. This makes it smaller, more comprehensible, with slighylu
smaller object size.

move PL_defgv nearer the top of intrvar.h

on the grounds that its a reasonably hot variable.

pp_entersub(): tweak some vars

make the scope of item be smaller;
don't assign +1 to MARK when we will shortly overwrite it;
use a local var to to store &GvAV(PL_defgv) to avoid recalculating it
use a _NN variant of SvREFCNT_inc

Shaves 2% off the object size of pp_entersub.

pp_entersub(): assign CvDEPTH to a local var

stop repeatedly retrieving it

pp_entersub(): re-indent block

the previous commit wrapped a switch statement in an if(), so re-indent
accordingly. Whitespace-only change.

tweak pp_entersub

liberally sprinkle some LIKELY()s, initialise gimme closer to where
it's first needed, and shortcut the common case of a GV with valid CV,
skipping the switch statement.

With gcc and x86_64, this reduces the code size of the function by
about 5%.

Remove spurious assert

kid is always dereferenced before the assert.

Remove leftover Windows 95 / Windows NT4 support code

We only support building or running on Windows 2000 or higher, as of the
Windows 95 Chainsaw Massacre commit (8cbe99e5b6). These three chunks of
code escaped the massacre, but the chainsaw has finally caught up with them
now.

List-OP removal: Fix compile fail on C90

Apologies. I'd applied Reini's patch to my optimization branch. I think
it got lost when I switched to Dave's variant my original code (which
didn't have Reini's C90 fix). Sorry!

Optimization: Remove needless list/pushmark pairs from the OP execution

This is an optimization for OP trees that involve list OPs in list
context. In list context, the list OP's first child, a pushmark, will do
what its name claims and push a mark to the mark stack, indicating the
start of a list of parameters to another OP. Then the list's other
child OPs will do their stack pushing. Finally, the list OP will be
executed and do nothing but undo what the pushmark has done. This is
because the main effect of the list OP only really kicks in if it's
not in array context (actually, it should probably only kick in if
it's in scalar context, but I don't know of any valid examples of
list OPs in void contexts).

This optimization is quite a measurable speed-up for array or hash
slicing and some other situations. Another (contrived) example is
that (1,2,(3,4)) now actually is the same, performance-wise as
(1,2,3,4), albeit that's rarely relevant.

The price to pay for this is a slightly convoluted (by standards other
than the perl core) bit of optimization logic that has to do minor
look-ahead on certain OPs in the peephole optimizer.

A number of tests failed after the first attack on this problem. The
failures were in two categories:

a) Tests that are sensitive to details of the OP tree structure and did
verbatim text comparisons of B::Concise output (ouch). These are just
patched according to the new red in this commit.

b) Test that validly failed because certain conditions in op.c were
expecting OP_LISTs where there are now OP_NULLs (with op_targ=OP_LIST).
For these, the respective conditions in op.c were adjusted.

The change includes modifying B::Deparse to handle the new OP tree
structure in the face of nulled OP_LISTs.

Macro for common OP checks: "is this X or was it before NULLing?"

For example,

    if (OP_TYPE_IS_OR_WAS(o, OP_LIST))
        ...

is now available instead of either of the following:

    if ( o
         && ( o->op_type == OP_LIST
              || (o->op_type == OP_NULL
                  && o->op_targ == OP_LIST) ) )
        ...

    if ( o &&
         (o->op_type == OP_NULL ? o->op_targ ? o->op_type) == OP_LIST )
        ...

In case the above logic is a bit unclear: It checks whether that OP is
an OP_LIST or used to be one before being NULLed using op_null.
(FTR, the resulting OP_NULLs have their op_targ set to the old OP type).

This sort of check (and it's reverse "isn't and didn't use to be") are a
relatively common pattern in the part of op.c that tries to intuit
structures from optimization-mangled OP trees. Hopefully, using these
macros will make some code a fair amount clearer.

Remove IO::Socket::IP examples as per Porting/Maintainers.pl

Update Pod-Perldoc to CPAN version 3.23

  [DELTA]

3.23 - Sun Feb 23 18:54:43 UTC 2014
    * Release 3.23

    Yes, this is a packaging error. Mea culpa. In the future
    test releases will be 3.23_01, etc.

    See https://twitter.com/frioux/status/429245594180128769
    for context.

3.22_02 - Wed Feb  5 05:08:34 UTC 2014
    * Add a pager that doesn't redirect stdin RT#85173
      Added a special pager environment variable for use
      when perldoc is in the -m mode that doesn't
      redirect STDIN.  Set PERLDOC_SRC_PAGER to use.

      As in:

      PERLDOC_SRC_PAGER=/usr/bin/vim perldoc -m File::Temp

    * Teach ToTerm.pm to get terminal width RT#85467
      Get a terminal width and pass it to Pod::Text::Termcap
      from one of these sources (in order):
          1. An explicit width set from command line with -w
          2. MANWIDTH environment variable
          3. stty output
          4. The default width of 76 (same as Pod::Text)

3.22_01 - Sat Feb  1 05:00:13 UTC 2014
    * Match =item more carefully when scanning perlfunc.
      Fixes RT #86795. Previously matches could be generated
      on words like 'size' and 'precision' which are not
      Perl functions.
    * Cleanup code related to mandoc RT #85844
      Patch by Ingo Schwarze
    * Re-add '-U' flag to skip attempting to drop
      privileges. RT #87837
    * Do not install to INSTALLDIRS after Perl 5.11 RT #89756
    * Refactor search_perlop (finds operators like 'q'
      'qq' 'tr' and others) RT #86506. Previously most of
      the text generated was incorrect.
    * Fix wrong version in DEBUG output from ToTerm.pm RT #85468
    * Fix POD errors when scanning parts of perlfunc RT #86472
      Patch by Shlomi Fish.

Update CPAN-Meta-YAML to CPAN version 0.012

Includes cc53c151 fix for VMS

  [DELTA]

0.012     2014-02-24 13:07:18-05:00 America/New_York

  - Generated from ETHER/YAML-Tiny-1.61.tar.gz

Update IO-Socket-IP to CPAN version 0.29

  [DELTA]

  0.29  2014/02/24 16:06:29
        [BUGFIXES]
         * Workaround for OSes that disobey AI_ADDRCONFIG and yield AIs on
           families the kernel will not support anyway (e.g. HPUX)
         * Workaround for OSes that lack getprotobyname() (e.g. Android)

Fix RT #121321 - Fencepost error causes infinite loop in regex compilation

Due to a fencepost error if a pattern had more than 9 capture buffers
and after the last capture buffer there was an octal style escape which
when interpreted as decimal evaluated to one more than the number of
defined buffers then the regex compiler would go into an infinite loop.

This fixes the fencepost error, adds tests, and adds some comments to
explain what is going on.

Use a temporary file instead of $^X when testing stat.

Otherwise there's a subtle race condition on the last access time, which can
cause the test to spuriously fail. I'm surprised that we've not seen this
failure until today.

Silence some VC++ compiler warnings

gv.c(1455) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
gv.c(1586) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
gv.c(2122) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
toke.c(12423) : warning C4244: '=' : conversion from 'I32' to 'char', possible loss of data
win32.c(3017) : warning C4022: 'SetHandleInformation' : pointer mismatch for actual parameter 1
win32.c(2971) : warning C4101: 'old_h' : unreferenced local variable
win32.c(2967) : warning C4101: 'oldfd' : unreferenced local variable

lib/locale.t: Make more tests not fail unless is bad for enough locales

locale.t has some tests that fail even one locale fails; and it has some
tests where failure doesn't happen unless a sufficient percentage of
locales have the same problem.

The first set should be for tests whose failure indicates a basic
problem in locale handling; and the second set should be for tests where
it could be that just a locale definition is bad.

Prior to this patch, tests dealing with radix problems were considered
in the first category, but in fact it's possible that just the locale
definition for the radix is wrong.  This is what happened for some older
Darwin versions for their Basque locales, which caused locale.t to show
failures, whereas it was just these locales that were bad, and the
generic handling was ok, or good enough.  (The actual failures had the
radix be the two character string: apostrophe followed by a blank.  It
would be a lot of work to make Perl deal with having a quote character
also mean a decimal point, and that work isn't worth it, especially as
this was a locale definition error, and we don't know of any locale in
the world where an apostrophe is legitimately a radix character.)

For this commit, I looked through the tests, and I added the tests where
it seemed that the problem could just be a bad locale definition to the
list of such tests.  Note that failures here could mean an internal Perl
error, but in that case, it should affect many more locales, so will
show up anyway as the failure rate should exceed the acceptable one.

lib/locale.t: Change an array to a hash

This is more naturally a hash in that it is a list of numbers, not
necessarily consecutive, and each time through the loop the same number
was getting pushed, so had multiple entries for each by the time it was
finished.

Missing version bump for Deparse

Not a good run, I am having. But also not anything tangible
that our silly tests caught me on. :(

Test fix: Update list of B::Concise functions

Imagine there was a test that actually broken open a core module's
package and looked at all of its subs and compared it to a hardcoded
list of "constant" and "xs" functions. That would be madness, wouldn't
it? Breaking encapsulation, no less? Require tedious synchronization?

m(

B::Deparse: Padrange deparse fix

The PADRANGE support fakes up a PUSHMARK OP but until this commit, it
did so incompletely since it never overrode the OP type (that was still
an OP_PADRANGE). This addresses that.

On top of it, there's two minor changes that switch from "eq" to "=="
for comparing numeric OP types.

fix RT #121299 - Inconsistent behavior with backreferences nested inside subpattern references

Match variables should be dynamically scoped during GOSUB and GOSTART.
The callers state should be inherited by the callee, but once the callee
returns, the callers state should be restored.

This is different from EVAL, where the callers and callees state are
expected to not be the same (although might be the same), and where
the "reasonable" match semantics differ. Currently the following two
one liners will produce different results:

$ ./perl -Ilib -le'"<ab><>>" =~/ < (?: \1 | [ab]+ ) (>) (?0)? /x and print $&;'
<ab><>>

$ ./perl -Ilib -le'$qr= qr/ < (?: \1 | [ab]+ ) (>) (??{ $qr })? /x; "<ab><>>" =~ m/$qr/ and print $&;'
<ab>

While I think reasonable people could argue that we should special case
things when we know that the return from (??{ ... }) is the same as the
currently executing pattern I think explaining the difference would be
harder than necessary.

On the contrary making GOSUB/GOSTART exactly the same as EVAL, so that
the match vars were totally independent seems to throw away an
opportunity for much more powerful semantics than can be offered by
EVAL.

Improve how regprop dumps REF-like nodes during execution

We pass in the regmatch_info struct, which allows us to dump
what a given REF is going to match.

comments and whitespace fixups to inprove clarity of the code

test nit in CPAN-Meta-YAML/t/31_local_tml.t

Directories on VMS have a .DIR extension.  This test appears to be
constructing method names from directory names, so we need to trim off
the extension to get it to pass.

Awaiting upstream application at:

https://rt.cpan.org/Public/Bug/Display.html?id=93297

fix win32 build

dca36a0cc embedded #ifdefs within a macro call, which is naughty (I
think). So have the ifdef outside the macro instead

[perl #121259] Always allow COW after $input=<>

sv_grow provides an extra byte for the sake of copy-on-write’s buffer
reference count, but skips this for multiples of 256 (though the com-
ments there say powers of two).

When we do

    $input=<>

The assignment is optimised away and the allocation takes place in
sv_gets.  In that code path, we know we don’t need a nice power of
two and allocating an extra byte won’t hurt, so go ahead and add an
extra byte.

This speeds up code doing m//g on $input, because it avoids the pre-
match copy.

Module-CoreList 3.07 released to CPAN, bump core version to 3.08

Fix syncing of Config-Perl-V with CPAN version 0.20

Commit d0fa2fb96e removed some erroneous changes made by commit 0b39d4dc4a
but didn't quite restore 21_plv518.t to match the CPAN version.

Upgrade HTTP-Tiny from version 0.042 to 0.043

perldelta for 257518b902

bump $base::VERSION to 2.22

[perl #121196] only examine the name being included

Checking the location called from broke require overrides.

perldelta for 3e63bed3c5, 58572ed82f

Update Module-Load to CPAN version 0.32

  [DELTA]

0.32    Thu Feb 20 22:53:19 GMT 2014
* Fix tests to support statically built perls

Only define Perl__get_regclass_nonbitmap_data once.

It was added in 77d654fbc7477bd but since it is exported, it
should not be defined in both the core and the extension versions
of regex code.  Doing so causes a multiply defined symbol warning
in the VMS linker and results in a build failure.  It might cause
trouble in any other environment with a strict linker.

[perl #120939] at least fix the leak in const_av_xsub

Update ExtUtils-MakeMaker to CPAN version 6.90

  [DELTA]

6.90 Thu Feb 20 20:46:04 GMT 2014

    No changes from 6.89_01

6.89_01 Mon Feb 17 15:56:39 GMT 2014
    Bug fixes:
    * Libraries are not transitive on Android

Restore proper functioning of -Mdiagnostics

Commit 1c604e7c7f fixed some pod errors, but broke

./perl -Ilib -Mdiagnostics -e '$/=[]'

This fixes that.

Change 'semantics' to 'rules'

The term 'semantics' in documentation when applied to character sets is
changed to 'rules' as being a shorter less-jargony synonym in this case.
This was discussed several releases ago, but I didn't get around to it.

Change av_len calls to av_tindex for clarity

av_tindex is a more clearly named synonym for av_len, available starting
in v5.18.  This changes the core uses to it, including modules in /ext,
which are not dual-lifed.

Bump version numbers

These four core-only modules are about to be changed so that they call
av_tindex instead of av_len.  There's no chance that any of the version
numbers will need to be reverted, as we think that bumping a single-life
module's version is harmless.

Update ribasushi's e-mail address.

Fix pod typo (kentnl++)

One typo fix was missed in upgrading Config::Perl::V to 0.20

The modified for blead change has been reverted
The -V output as checked for 5.10.x and 5.18.x will not change
with changes in blead.

I will add new test files for all most recent maint releases
and will add one for 5.10.0 when it is out

Module-CoreList 3.06 released to CPAN

Amend Porting/core-cpan-diff

Allow -v with -x
Show diff for customized scripts when -d and -v
Allow -v #
Set -d if -v 3 and up

prepare Module::CoreList for next release

bump to version 5.19.10 and fix the version number reference in op.c

new perldelta for 5.19.10

avoid leaving the old perldelta as a symlink

In a built tree, the name we copy perldelta.pod to is a symlink to
perldelta.pod, and if you blindly follow the git adds, you end up
adding a symlink to the commit.

unlink() the name we're about to overwrite before we overwrite it to
prevent that.

record the 5.19.9 epigraph

merge 5.19.9 release branch

regcomp.c: Don't read uninitialized data

I keep forgetting that the OP of a regnode is not defined in Pass 1 of
the regex compiler.  This is likely the cause of inconsistent results in
lib/locale.t, as valgrind shows there to be a read of uninitialized
data before this patch, and the result is randomly tainting when there
shouldn't be, consistent with the test failures.

note lib/locale.t rare failure

update perlhist for 5.19.9

finalize perldelta for 5.19.9

Update Module::CoreList for 5.19.9

lib/locale.t: Remove tests that need UTF-8 locale

These tests should not be here because they will only match under a
UTF-8 locale, which happens to be the case on the machine I developed
them on, but not necessarily always true, and so they are failing.

Given the deadline is already past, I'm just removing them for now, and
will re-add them later in another place in the file where we know we
are using a UTF-8 locale.

locale.c: Change 'and' to '&&'

To actually compile on Windows

run/locale.t: White-space only

Align a column

locale.c: Another POSIX emulation fix on Windows

Right after I pushed the previous commit, I realized that the system
default locale on Windows should also have lower priority (besides LANG)
than the LC_foo environment variables.  This should do that.

.locale.c: Better emulate POSIX locale setting on Windows

Commit b385bb4ddcb252e69a1044d702646741e2e489fb introduced
my_setlocale() compiled only under Windows which emulates the POSIX
rules for setting the locale.  It differs from Windows only if the
locale passed in is "".  Unfortunately it was buggy if the category
being set was LC_ALL, and there is a LANG environment variable.  LANG
has lower precedence than the other environment variables, like
LC_NUMERIC, but my_setlocale() was giving it higher priority when set
through LC_ALL.

This should solve the problems being seen since
7cd8b56846670e577e1f62479eab8f38fb11da14

Make taint checking regex compile time instead of runtime

See discussion at https://rt.perl.org/Ticket/Display.html?id=120675
There are several unresolved  items in this discussion, but we did agree
that tainting should be dependent only on the regex pattern, and not the
particular input string being matched against:

"The bottom line is we are moving to the policy that tainting is based
on the operation being in locale, without regard to the particular
operand's contents passed this time to the operation. This means simpler
core code and more consistent tainting results. And it lessens the
likelihood that there are paths in the core that should taint but don't"

This commit does the minimal work to change regex pattern matching to
determine tainting at pattern compilation time.  Simply put, if a
pattern contains a regnode whose match/not match depends on the run-time
locale, any attempt to match against that pattern will taint, regardless
of the actual target string or runtime locale in effect.  Given this
change, there are optimizations that can be made to avoid runtime work,
but these are deferred until later.

Note that just because a regular expression is compiled under locale
doesn't mean that the generated pattern will be tainted.  It depends on
the actual pattern.  For example, the pattern /(.)/ doesn't taint
because it will match exactly one character of the input, regardless of
locale settings.

lib/locale.t: Add some test names

lib/locale.t: Untaint before checking if next thing taints

The tests weren't testing what they purported to, as we should be sure
to start with untained values to see if the operation taints.

perllocale: Add note about ENVIRONMENT variable

This variable is part of the environment, but wasn't previously
mentioned.

perlsec: Nit

Update Config::Perl::V to 0.20

perlootut: replace Object::Tiny with Class::Tiny

Class::Tiny is similarly small and simple in API, but with more powerful
features available.  Comparison to Object::Tiny and Class::Accessor is
here: https://metacpan.org/pod/Class::Tiny#RATIONALE

At mst's suggestion, a link to Class::Tiny::Antlers for Moose-syntax
is included.

New bincompat options

regcomp.c: Remove no longer used function

I don't think this function will need to be used again.

regcomp.c: Move some locale initialization code

This moves some code down a few lines, rewording the comments, and doing
some things only once, instead of each time through the loop.

This eliminates some tests, as the new place already has determined that
some of the preconditions for executing the code have been met.  It
keeps us from generating unnecessary locale nodes for platforms which
don't have isascii().

regcomp.c,regexec.c: White-space only

Properly indent two sections of code newly enclosed in braces by the
previous commit

regcomp.c: Fix more alignment problems

I believe this will fix the remaining alignment problems recently being
shown on gcc on HP-UX, It works on the procura machine.

regnodes should not have stricter alignment than required by U32, for
reasons given in the comments this commit adds to the beginning of
regcomp.h.  Commit 31f05a37 added a new ANYOF regnode struct with a
pointer field.  This requires stricter alignment on some 64-bit platforms,
and hence doesn't work on those platforms.

This commit removes that regnode struct type, and instead stores the
pointer it used via a more indirect, but already existing mechanism
that stores other data..

The function that returns that other data is enlarged to return this new
field as well.  It now needs to be called from regcomp.c, so the
previous commit had renamed and made it accessible from there.  The
"public" function that wraps this one is unchanged.  (I put "public" in
quotes here, because I don't think anyone outside core is or should be
using it, but since it has been publicly available for a long time, I'm
treating the API as unchangeable.  regcomp.c called this public function
before this commit, but needs the additional data returned by the inner
one).

regexec.c: Rename function, add parameter, make non-static

This is in preparation for a future commit where the function does more
things so its current name would be misleading.  It will need to be
callable from regcomp.c as well.

regcomp.h: Allow compiler to perform calculation

Instead of doing the calculation of how many bytes a 256 bitmap
occupies, let the compiler do it.  I believe we are not too far away
from having the ability to allow applications to recompile Perl to
increase the bitmap size trading speed for memory.  ICU has an 8192
bitmap last time I checked.

regexec.c: Add some checks

These aren't currently needed, but a future commit will change so things
need to be more general

Change method of passing some info from regcomp to regexec

For the last several releases, the fact that an ANYOF node could match
something outside its bitmap has been passed to regexec.c by having its
ARG field not be -1 (appropriately cast).  A bit was set if the match
could occur even if the target string was not UTF-8 encoded.  This
design was used to save a bit, as previously there was a bit also for it
matching UTF-8 strings.

That design is no longer tenable, as a future commit will have a third
(independent) reason for something to match outside the bitmap,  This
commits uses the current spare bit flag to indicate if the match can
only occur if the target string is UTF-8.

regcomp.h: Remove extraneous comment

This is obsolete and is a partial copy of the up-to-date comment below
it.

regcomp.h: Free up flag bit in ANYOF nodes

The ANYOF_LOC bit was removed from final use in the previous commit.

regexes: Remove uses of ANYOF_LOCALE flag

This flag no longer adds any useful information and can be removed.  An
ANYOF node that depends on locale either matches a POSIX class like /d,
or matches case insensitively, or both.  There are flags for both these
cases, and to see if something matches locale, one merely needs to see
if either flag is set.

Not having to keep track of this extra flag simplifies things, and will
allow it to be removed.  There was a time when this flag was shared with
one of the remaining locale ones, and there was relict code that allowed
that sharing to be reinstated, and which this commit also removes.