Don't create locale object unless threaded

PL_C_locale_obj is now only created on threaded builds on systems with
POSIX 2008.  On unthreaded builds, we really should continue to use the
old tried and true library calls.

perl.h: Move some locale definitions around

For clarity, this places these locale definitions that depend solely on
having locales or not earlier, and by themselves, so don't get mixed up
with the definitions that have more complicated provenances.

In moving them, I also changed white space to accepted indentations,
and vertical alignment.

perl.h: Rmv dummy definitions

These macros are core-only, so should generate a compiler error if used
outside of core, instead of compiling as no-ops.

Don't create unneeded mutexes

These mutexes are needed only for unsafe threaded-locale operations.

Langinfo: Implement CODESET on Windows

This applies to I18N::Langinfo, and the API function Perl_langinfo.
Windows doesn't have nl_langinfo, so an emulation is used.  It turns out
that it is easy to emulate the behavior for the CODESET item on Windows,
as that vendor has kept things consistent.

PATCH: [perl #127288] I18N::Langinfo sets UTF-8 bit

This commit will turn UTF-8 on in the returned SV if its string is legal
UTF-8 containing something besides ASCII, and the locale is a UTF-8 one.
It is based on the patch included in the ticket, but is generalized to
handle edge cases.

I18N::Langinfo: fix pod nits

Removing trailing space; fix typo, clarify

perlapi: Clarifications to Perl_langinfo

Actually make I18N::Langinfo avail on all platforms

I thought I had done this earlier, but testing on Windows demonstrated
that I hadn't.

While at it, move the details in the docs for Perl_langinfo to the
module's pod.

This doesn't follow the paradigm for putting the Configure stuff in all
the related configure files, but I saw no point to doing so.  If you are
reading this because I was wrong, feel free to ticket it or fix it.

Change enum names for new locale function parameters

Earlier in the 5.27 series, I introduced Perl_langinfo which calls
the system nl_langinfo() on platforms that have it, and emulates it
otherwise.  For each enum parameter 'foo', I made an equivalent
parameter PERL_foo.  I did this so that no conflicts would arise if
any 'foo' were negative.  This is less than ideal to have to rename the
parameters.

In looking further, I realized that perl has always excluded the
possibility of negative values for 'foo', so my precaution is
unnecessary.  And before this new code is released is the time to fix up
the interface.

APItest/t/locale.t: Store hash return for readability

APItest/t/locale.t: Sort some tests

These now appear in the file in their logical order

Carp: Use ${^LAST_FH} if available

Using ${^LAST_FH}, available in 5.18, in faster than using eval/die
to get the last file handle.

Also, the eval/die method is not going to produce anything if $. is 0
so skip that entire block if $. is false (by removing the defined check).

(Not significant enough for perldelta.  carp("zonk") gets faster by
only 5% or so.)

Let cmp_version be run from the top level

I’m used to typing ‘./perl -Ilib t/porting/cmp_version.t’; it’s annoy-
ing to have to add ‘-I.’.

(Obviously no perldelta entry necessary.)

warnings.pm: sprintf is faster than concat

I benchmarked this line alone in a one-liner and found the sprintf
variant to be roughly 10% faster than the concat version.  It’s also
more readable (and maintainable).

(Not significant enough to warrant a perldelta entry.)

(perl #127743) re-work for debugging builds with MSVC

My original change here broke debugging builds, since tmp was no longer
available for the TRACEME.

t/lib/croak/regcomp: Another attempt to fix test failure

Commit e10187a7905cc53ffe233c0f091b3a7b3a6da4a9 failed to entirely fix
the failure, and this expands on that.

I had forgotten the pitfalls of using literal non-ASCIIs in tests

perlrequick: Nits, clarifications

regcomp.c: Quiet false warning

One compiler is complaining that this variable may be used
uninitialized.  It's not true, but set it to NULL anyway.

t/lib/croak/regcomp: Hopefully fix test failure

This is failing on H. Merijn Brand's machines.  I can't reproduce it
there, but it makes sense that it has something to do with printing a
non-ASCII character, given that it's only failing under a particular
locale.  So try this simple solution.

Avoid goto into glob test failure on VMS.

glob() does not return a list on VMS, so joining its result fails
expectations for this test.

locale.c: Add missing STATIC

Spotted by H. Merijn Brand

remove empty file

add an empty file (to be removed next commit)

Don't run stack_after_err.t on VMS.

It uses IPC::Open3, which uses fork(), which doesn't exist.

fix line numbers in multi-line s///

my commit v5.25.6-230-g6432a58, "Eliminate SVrepl_EVAL and SvEVALED()",
introduced a regression: __LINE__ no longer took account of multiple
lines in the s///.

Now fixed.

Spotted by Abigail.

(perl #132870) workaround VC2017 compiler bug

For non-debug builds MSVC could read small integers like 1 as -255.

It's possible it was confused by the AIX compiler bug workaround.

This change needs no further tests, the integer.t fails without
this workaround.

rmv/de-dup static const char array "strings"

MSVC due to a bug doesn't merge identicals between .o'es or discard these
vars and their contents.

MEM_WRAP_CHECK_2 has never been used outside of core according to cpan grep
MEM_WRAP_CHECK_2 was removed on the "have PERL_MALLOC_WRAP" branch in
commit fabdb6c0879 "pre-likely cleanup" without explination, probably bc
it was unused. But MEM_WRAP_CHECK_2 was still left on the "no
PERL_MALLOC_WRAP" branch, so remove it from the "no" side for tidyness
since it was a mistake to leave it there if it was removed from the "yes"
side of the #ifdef.

Add MEM_WRAP_CHECK_s API, letter "s" means argument is string or static.
This lets us get rid of the "%s" argument passed to Perl_croak_nocontext at
a couple call sites since we fully control the next and only argument and
its guaranteed to be a string literal. This allows merging of 2
"Out of memory during array extend" c strings by linker now.

Also change the 2 op.h messages into macros which become string literals
at their call sites instead of "read char * from a global char **" which
was going on before.

VC 2003 32b perl527.dll section size before
  .text name
   DE503 virtual size
  .rdata name
   4B621 virtual size

after
  .text name
   DE503 virtual size
  .rdata name
   4B5D1 virtual size

File::Glob bsd_glob.c dont use "loop" as a goto label

Using loop as a label conflicts with Perl's "struct loop" and "LOOP" types
and Visual C 2003 in C++ mode (but not the default C build) doesn't like
that. The loop label is from 5.27.1 commit 0db967b2e6
"[perl #131211] fixup File::Glob degenerate matching"

bsd_glob.c(995) : error C2226: syntax error : unexpected type 'loop'

PATCH: [perl #132163] regex assertion failure

The original test case in this ticket has already been fixed; but
modifying it slightly showed some other issues that are now fixed by
this commit.

The deepest problem is that this code in some paths creates a string to
parse instead of the original pattern.  And in some cases, it's not even
the original pattern, but something that had already been created to
parse instead of the pattern.  Any messages that are raised should be
output in terms of the original.  regcomp.c already has the
infrastructure to handle the case where a message is raised during
parsing of a constructed string, but it can't handle a 2nd level
constructed string.  That was what led to the segfault in the original
ticket.  Unrelated fixes caused the original ticket to no longer be
applicable, and so this fix adds tests for things still would cause a
problem.

The method chosen here is to just make sure that the string constructed
here to parse is error free, so no messages will be raised.  Instead it
does the error checking as it constructs the string, so if what is being
parsed to construct a new string is an already constructed one, the
existing infrastructure handles outputting the message relative to the
original pattern.  Since what is being parsed is a series of hex
numbers, it's easy to find out what their values are: just accumulate a
total, shifting 4 bits each time through the loop.  A side benefit is
that this fixes some unreported bugs dealing with an input code point
that overflows.  Prior to this patch, it would error ungracefully.

eliminate _REGEXP_COMMON macro from regexp.h

It is used in only one place now, so its better to expand it out rather
than having a complex struct's fields defined using a huge macro.

No functional changes, but I did take the opportunity to tidy up the
formatting of the code comments for each struct field

op_dump(): display op_next to self as [SELF]

Normally op_next (and similar) fields of an op are displayed with the
address and basic details of the op they point to, e.g.

    5    gvsv PADOP(0x1b7ac48) ===> 5 [sassign 0x1b7ab80]

This commit enhances that so that if the field points back to the op
containing the field (as is often the case during the early phases of
building an op tree), instead display it as just:

    5    gvsv PADOP(0x1b7ac48) ===> [SELF]

inline.h: #define some constants for EBCDIC

I thought these weren't needed on EBCDIC builds, but it turns out there
is occasion for them.

pp_repeat: avoid calling GIMME_V twice

assign its value to a local var instead. GIMME_V can have a considerable
overhead when called in unknown context.

I audited the rest of the pp*.c files, but didn't find any similar
multiple calls.

Tux' smoke reports moved

due to re-allocation of available hosts, Tux has now hosted the smoke
reports somewhere else

t/run/locale.t: Fix skip count; uninit warning

Spotted by Tony Cook

perldelta for b857191d01c2, 74e28a4a737c

(perl #132925) don't use $0 to get the name of mk_invlists.pl

Other regen scripts simply embed the name as a literal, using $0
means that the output varies depending on the path used to call
regen/mk_invlists.pl.

(perl #132925) correct path handling in mktables

the lexical my $file inside the loop masked the for loop $file,
wasting the work done to canonicalize the path names.

The grep on length is required since splitdir() can return empty
strings.

Revert "charclasslists.h: script enums visible to CORE,EXT"

This reverts commit fea79782ed31ac4faa71eb6193faff54b4bbe249.

This bloats perl, and is not now necessary for 5.28.

EBCDIC conditional compilation fixes

The recent changes fixed by this commit neglected to take into account
EBCDIC differences.

Mostly, the algorithms apply only to ASCII platforms, so the EBCDIC is
ifdef'd out.  In a couple cases, the algorithm mostly applies, so the
scope of the ifdefs is smaller.

regexec.c: White-space only

Properly indent preprocessor directives

inline.h: White-space only

Properly indent preprocessor directives

perldiag: Rewrap an entry for better splain output

The splain utility (aka diagnostics.pm) blindly strips out pod formatting
without rewrapping the text (I think rewrapping would be overkill).  This
means that formatting like ‘L<Note [5] in
perlrecharclass|perlrecharclass/[5]>’ turns into a simple ‘Note [5] in
perlrecharclass’, which can mess up the indentation.

Rewrap the entry to compensate, plus a few other tweaks to improve
the appearance of the right margin.

More AUTHORS sorting

AUTHORS: sorting; consistent indent

Increase ExtUtils::ParseXS(::*) version to 3.39

Add Shoichi Kaji to AUTHORS

RT #132935: correctly check VERSIONs in ExtUtils::ParseXS

The following version check does not work correctly:

BEGIN { $VERSION = '3.38' }
use ExtUtils::ParseXS::Constants $VERSION;

The reason is that we must use version "literals",
not "variables" in `use Module VERSION`.
For the sake of ease of maintenance,
we use "require" and "->VERSION", instead of "use" here.

perldiag typo

RT #132834: prevent duplicate Config.pm vars

Commit 6c2ae6421675ba5ff81dd43f9167136f02dfe9d9 introduced variables whose
need was forced by configpm (for compatibility with older software), but
incorrectly added those variables to the generated Config_heavy.pl even when
they were already in use.

The resulting duplicate variables are clearly wrong, and in addition they
broke ExtUtils::InferConfig.

loc_tools.pl: Properly exclude iffy locales

This code (fragiley) uses the wording of a warning message to determine
if a locale has issues or not.  Commit
578a6a873a320fe64743b060dbd467f1865d205c updated the message this is
looking for, but failed to update this file correspondingly.

perlapi: utf8_to_uvuni_buf() Add clarification

t/run/locale.t: Add, revise tests

This enhances the test added in bee74f4b9818f0ca72926dd6b4dfdbc6b75c59ef
so that it is doing a valid setlocale, and adds a similar test for doing
an invalid one.

t/loc_tools.pl: Add fcn to return valid locale cats

This new function will return the locale categories known to this
platform.

t/run/locale.t: Update skip count

This should have been updated by
bee74f4b9818f0ca72926dd6b4dfdbc6b75c59ef.

locale.c: Fix bug in parsing a locale

This was not handling the case where there is a semi-colon separated
list of individual locales, except the last one had no trailing
semi-colon.

Thanks to Sergey Aleynikov for finding this

locale.c: Check return code

In cases like these, we should give up if the called function fails.

locale.c: Replace an 'if' by an assert

This should be true if we get to here.

locale.c: Increase debug buffer size

A case was found where this was too small

locale.c: Rmv spurious Safefree

I misread the documentation, and Perl_form doesn't need its return value
freed; it's already declared to be temporary, so if this code actually
got executed, there'd be a wrong pool panic

locale.c: Remove redundant SAVE_ERRNO

The errnos were already saved just above

perlguts: Clarify an example.

Reword warning for deviations from UTF-8 locales

Some locales are UTF-8, but not exactly what Perl is expecting.  Revise
the message raised in this circumstance.

Originally I thought these were violations of Unicode, but based on
feedback from Craig Berry, I came to realize that these are legitimate
interpretations of the Unicode standard.  But perl persists with its own
interpretation that differs from these, hence the warning.

Bump version of POSIX.pm to 1.83; warnings to 1.42

These were made using the old version number, and the error was not
caught, because of the lateness in getting 5.27.9 tagged

perldelta typo

perldelta for Carp changes since 5.27.9

Most of the commits that modified Carp.pm were either minor fix-ups
for previous commits or fixes for bugs introduced by previous commits.
Hence, there are validly only three entries, even though it seems
a small number for such a flurry of activity.

All significant Carp changes prior to this commit are accounted for.

Remove 5.27.9 entries from 5.27.10’s delta

regen

Bump Module::CoreList

Bump version

New Perldelta

Tick release in release schedule

Update epigraph.pod

mg.c: Fix isSCRIPT_RUN call

Commit 49cd072660b3b1858be5f27df107b3b42498a3f3 failed to fix up this
call to isSCRIPT_RUN, which is typically only compiled on Windows.

[MERGE] fixups for attributes-before-signatures

RT #132760

v5.27.7-212-g894f226 recently moved subroutine attributes from after
the signature to before the signature.

This small branch performs some minor tweaks to that; principally:

* splits the parser rules for subs into separate rules for subs
within and without the scope of 'use feature "signatures";

* makes the parser and toker recognise the possibility of attributes
following the signature, so that a targeted error message can be given,
rather than a general 'syntax error' and follow-on dross.

detect sub attributes following a signature

RT #132760

A recent commit (v5.27.7-212-g894f226) moved subroutine attributes back
before the subroutine's signature: e.g.

    sub foo :prototype($$) ($a, $b) { ... }  # 5.18 and 5.28 +
    sub foo ($a, $b) :prototype($$) { ... }  # 5.20 .. 5.26

This change means that any code still using an attribute following the
signature is going to trigger a syntax error. However, the error, followed
by error recovery and further warnings and errors, is very unfriendly and
gives no indication of the root cause. This commit introduces a new error,
"Subroutine attributes must come before the signature".

For example, List::Lazy, the subject of the ticket, failed to compile
tests, with output like:

    Array found where operator expected at blib/lib/List/Lazy.pm line 43,
    near "$$@)" (Missing operator before @)?)
    "my" variable $step masks earlier declaration in same statement at
    blib/lib/List/Lazy.pm line 44.
    syntax error at blib/lib/List/Lazy.pm line 36, near ") :"
    Global symbol "$generator" requires explicit package name (did you
    forget to declare "my $generator"?) at blib/lib/List/Lazy.pm line 38.
    Global symbol "$state" requires explicit package name (did you forget
    to declare "my $state"?) at blib/lib/List/Lazy.pm line 39.
    Global symbol "$min" requires explicit package name (did you forget to
    declare "my $min"?) at blib/lib/List/Lazy.pm line 43.
    Global symbol "$max" requires explicit package name (did you forget to
    declare "my $max"?) at blib/lib/List/Lazy.pm line 43.
    Global symbol "$step" requires explicit package name (did you forget
    to declare "my $step"?) at blib/lib/List/Lazy.pm line 43.
    Invalid separator character '{' in attribute list at
    blib/lib/List/Lazy.pm line 44, near "$step : sub "
    Global symbol "$step" requires explicit package name (did you forget
    to declare "my $step"?) at blib/lib/List/Lazy.pm line 44.

But following this commit, it now just outputs:

    Subroutine attributes must come before the signature at
    blib/lib/List/Lazy.pm line 36.
    Compilation failed in require at t/append.t line 5.
    BEGIN failed--compilation aborted at t/append.t line 5.

It works by:

1) adding a boolean flag (sig_seen) to the parser state to indicate that a
   signature has been parsed;
2) at the end of parsing a signature, PL_expect is set to XATTRBLOCK
   rather than XBLOCK.

Then if something looking like one or more attributes is encountered
by the lexer immediately afterwards, it scans it as if it were an
attribute, but then if sig_seen is true, it croaks.

subtly change meaning of XATTRBLOCK, XATTRTERM

Currently they tell the toker that the next thing will be attributes,
followed by an XBLOCK or XTERMBLOCK respectively.

This commit subtly changes their meanings so that they indicate that
attributes legally *might* follow. This makes the code which initially
sets them slightly simpler (no need to check whether the next char is
':'), and the code elsewhere in yylex() which handles XATTR* only triggers
if the next char is ':' anyway.

Doing it this way will shortly make detection simpler of an attribute
illegally following a signature.

rationalise subroutine parsing rules

Now that the parser rules have been split into separate rules for subs
under 'use feature "signatures"' and not, refine the rules to reflect the
different regimes. In particular:

1) no longer include 'proto' in the signature variants: as it happens the
toker would never return a proto THING under signatures anyway, but
removing it from the grammar makes it clearer what's expected and not
expected.

2) Remove 'subsignature' from non-sig rules: what used to happen before
was that outside of 'use feature "signatures"', it might still try to
parse a signature, e.g.

    $ perl5279 -we 'sub f :lvalue ($$@) { $x = 1 }'
    Illegal character following sigil in a subroutine signature at -e line
    1, near "($"
    syntax error at -e line 1, near "$$@"

Now it's just a plain syntax error.

parse subs and signature subs separately

Currently the toker returns a SUB or ANONSUB token at the beginning
of a sub (or BEGIN etc). Change it so that in the scope of
'use feature "signatures"', it returns a SIGSUB / ANON_SIGSUB token
instead.

Then in perly.y, duplicate the 2 rules containing SUB / ANONSUB
to cope with these two new tokens.

The net effect of this is to use different rules in the parser for
parsing subs when signatures are in scope.

Since the two sets of rules have just been cut and pasted, there should
be no functional changes yet, but that will change shortly.

add Perl_init_named_cv() functiom

This moves a block of code out from perly.y into its own function,
because it will shortly be needed in more than one place.

Should be no functional changes.

Merge remote-tracking branch 'renee/release-5.27.9' into blead

perl.h: Add comment about clang warnings

Commit b2f82b52000c3bfe6e6df200c775e2a639d91552 failed to document
details about the clang warnings.  This commit adds a link to clang's
documentation

Remove parameter from isSCRIPT_RUN

Daniel Dragan pointed out that this parameter is unused (the commits
that want it didn't get into 5.28), and is causing a table to be
duplicated all over the place, so just remove it for now.

Silence wrong clang warnings

Clang thread-safety analysis fails to correctly work in this situation
(and is documented as failing), so turn off that warning here.

numeric.c: Refactor code to use only one RESTORE

This code saves and restores the LC_NUMERIC locale.  This commit
refactors it so that only one RESTORE is done.  The reason is because
having two, depending on various data confuses clang's static analysis
of thread safety, leading to false positive scary warnings.

regen/regcomp.pl: close FH before unlink

On Win32, regen.pl failed if something caused different checksum for
perldebguts.pod and the old file was attempted to be unlinked/renamed, but
that was failing because the FH is still open (Win32 specific thing).
So close the FH before renaming the file instead of having scope exit close
the FH after close_and_rename() executes.

the fixed error console log:

changed 'pod/perldebguts.pod-new' to 'pod/perldebguts.pod'
Couldn't unlink pod/perldebguts.pod: Permission denied
renaming pod/perldebguts.pod-new to pod/perldebguts.pod: Permission denied at ./
regen/regen_lib.pl line 120, <$oldguts> line 1046.
Changed: pod/perldebguts.pod
C:\perl\bin\perl.exe -I. regen/regcomp.pl -v failed: 3328 at regen.pl line 20, <
DATA> line 8.

remove unused var in sv_eq_flags

svrecode became unused in commit 8df0e7a28b
"Remove IN_ENCODING macro, and all code dependent on it" but there was
still a SvREFCNT_dec(NULL) executed at the end of the function. This
commit will reduce size of Perl_sv_eq_flags by the CC not having to
save var eq to a non-volatile register or stack location around the
SvREFCNT_dec func call and instead store var eq in the return register
directly. Also remove the eq var completly, since initializing the var
so early means it has to be stored on the stack around alot func calls,
so just do a direct return of const zero on the only "fall off the end"
path in the func.

(perl #132893) don't probe for Storable recursion limits on old Win32

We hope to release 5.26.2 and 5.24.4 together in March

rework Carp/t/stack_after_err.t to not use perl -e

Carp: Speed up longmess some more

Commit 915a6810d added a UNIVERSAL::isa check to format_arg (used by
longmess, which generates stack traces) to see whether an argument is
blessed before trying CARP_TRACE, to speed things up when the argu-
ment is not blessed.

Because this would cause infinite recursion when the UNIVERSAL::isa
module is loaded, a check was put in place to avoid this problem.  But
the check was a run-time check, and so the speed-up was minimal.

If we move the check to compile time (and save the original
&UNIVERSAL::isa in case the module gets loaded later), then the speed-
up is signifant.  That is what this patch does.

Before this patch, the following one-liner runs on my machine in 6
seconds on average:

$ ./perl -MCarp -Ilib -e 'sub f { my $c = shift; if ($c == 100) { Carp::longmess() } else { f($c+1,{}) } } f(0,{}) for 1..500'

If I disable the isa check (just to see how much it was speeding
things up), it averages 6.5 seconds, not much of a difference.

If I move the $UNIVERSAL::isa::VERSION safety check to compile time
instead of run time, I can reduce the time to 4.9 seconds.

t/re/regexp.t: Silence HP-UX warnings

The tests that use t/re/re_tests may use a locale.  It doesn't much
matter which locale, except we want one that isn't going to generate
warnings.

perlapi: Fix typo

remove unreferenced copies of char * swash_property_names[]

Due to some MSVC bug or perl's not using MS specific CC options that I've
never figured out, MSVC does not remove unreferenced by a single .obj or
combine identical, static const data vars. MSVC funcs get removed &
combined correctly. Since for var swash_property_names removing it from
.objs that dont need it is very easy, do it. It saves some memory space.
Perhaps some other platforms/OSes/CCs have similar problems removing
unreferenced symbols from final binaries so this patch would help on those
CCs too.

regexec.c stopped using swash_property_names in commit 2a16ac9277 in 5.19.8
"regexec.c: Use compiled-in POSIX definitions"

regcomp.c stopped using swash_property_names in commit bcb875216f in 5.19.8
"regcomp.c: Rmv code for delayed 'til runtime POSIX defns"

with MSVC 2008 64, before

miniperl.exe disk file size 1761KB .rdata virtual size 0xBC354 bytes
perl527.dll disk file size 2040KB .rdata virtual size 0xC9421 bytes

after this commit

miniperl.exe disk file size 1761KB .rdata virtual size 0xBC2C4 bytes
perl527.dll disk file size 2040KB .rdata virtual size 0xC9381 bytes

~144 bytes saved by removing unused copies of swash_property_names array.

There are other cases of large duplicate static const data vars still in
the perl527.dll binary but this patch covers a very simple case.

warnings.pm: _at_level functions and chunky handles

The _at_level functions, which have to bypass Carp, were not
reporting non-line-based filehandles correctly.  The perl core
does:

    ..., <fh> chunk 7.

if $/ is not "\n".  warnings.pm should do the same.  It was using
‘line’.

Carp: Avoid run-time mods; StrVal workarounds

Carp needs to avoid loading modules while reporting errors, because
it may be invoked via $SIG{__DIE__} after a syntax error, when BEGIN
blocks are forbidden.

Before this commit (as of v5.27.8-360-gc99363a) it was doing just that
for reference arguments within stack traces.

That means we either need to load overload.pm at start-up so that
overload::StrVal is already available, or avoid overload::StrVal
altogether.

It turns out that various versions of overload::StrVal have
their own problems that prevent Carp from using them (out-
lined in the comments added to Carp.pm and also described at
<https://rt.perl.org/Ticket/Display.html?id=132902#txn-1535564>).

So we now follow two approaches:  If overloading.pm is available, use
that; otherwise, use a hideous workaround inspired by ancient imple-
entations of overload::StrVal and Scalar::Util::blessed, while avoid-
ing the bugs in those old versions.

op.h: remove spurious #  define indent

whitespace-only change

ext/File-Glob/t/rt131211.t: fix timing issues

This test file occasionally fails test numbers 1 and/or 2 on smokes.
These two tests measure how long it takes to do a matching and
non-matching glob() with a lot of "a*a*a*...." and fail if the
match and non-matching times differ too much (the original bug was that
non-match went exponential on number of "a*"'s).

However, on good systems, the timings returned are typically
sub-millisecond, so I'm guessing the occasional failures are due to

(small measured noise) * 100  > (another small measured noise).

So this commit avoids tests 1&2 failing unless the values measured
are large enough not to be merely noise.

This is just speculation on my part though - I couldn't reproduce a
failure myself.

(perl #127743) don't probe Storable limits so much (Win32 makefiles)

Win32 port of the changes in 8175eebc32