Include the Win32 extension in the ALL_STATIC build on Win32

Many of Win32's Perl level functions are pre-defined (even without a "use
Win32" statement), while the implementation is in a dynamically linked
module. This is done via the statically linked Win32CORE wrapper that will
load Win32 on demand. The initialization of Win32CORE (init_Win32CORE()) is
called -- dynamically, via GetProcAddress(), since miniperl.exe doesn't
include it -- from Perl_init_os_extras() and normally relies on the DLL's
HANDLE having been set in the DLL_PROCESS_ATTACH case of DllMain() in
perllib.c. We must use a different HANDLE when the functions are located in
perl-static.exe since DllMain() is not called in that case, and, in fact,
it is sensible to consider other parts of DllMain() which
Perl_init_os_extras() might also need to do...

The #ifdef DEFAULT_BINMODE section can be scrapped completely since the
symbol is not defined, never mentioned anywhere else and not documented.
The DisableThreadLibraryCalls() call is not applicable for code that
doesn't reside in a DLL. That just leaves set_w32_module_name(), but that
is not required either, and may actually be redundant in the DllMain() case
too (maybe I will remove it later).

The last-but-one thing to do is to arrange for init_Win32CORE to be
exported from perl-static.exe (as it already is from perl519.dll, courtesy
of makedef.pl) otherwise GetProcAddress() won't find it. I see no harm in
always specifying __declspec(dllexport) in Win32CORE.c (except in one
existing Cygwin case which doesn't want it, which I'm not touching to
minimize regression risk). I thought that the .def file entry written by
makedef.pl for perl519.dll would then become redundant, and whilst the VC++
build worked fine without it, the MinGW build didn't: init_Win32CORE no
longer got exported from perl519.dll, thus breaking the normal build, so
I've therefore left makedef.pl alone.

The very last thing to do in some future change is to improve the
ALL_STATIC build so that Win32 functions like CopyFile() do not go
through Win32CORE's w32_CORE_all forwarding function as they currently do:
it isn't necessary when Win32 is statically linked as well! I will revisit
this part very soon...

Thanks to Jan Dubois and all the others in the following thread for
invaluable assistance in this and other recent changes in this area:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2013-06/msg00016.html
Include the Encode extension in the ALL_STATIC build on Win32 for VC++

Thanks to Jan Dubois and Nicholas Clark for pointing out that Encode has
subextensions which need statically linking too, and that Configure has
a special case for handling this which we can mimic in config_sh.PL.

Unfortunately, however, while this works for VC++, with MinGW it gives
undefined reference errors to three symbols from Encode/CN.o
(_cp936_encoding, _euc_cn_encoding and MacChineseSimp_encoding) and two
from Encode/JP.o (_cp932_encoding and _euc_jp_encoding), so we must retain
the exclusion on Encode for MinGW for now, much like the Compress/Raw/Bzip2
problem found before. Hopefully these are all fixable soon.
perldiag: Correct descr of ‘Expecting '(?flags:(?[...'’

I did not realise at first that (?:(?[...])) is forbidden.
Allow qr/(?[ [a] ])/ interpolation in (?[...])

Interpolation fails if the interpolated extended character class con-
tains any bracketed character classes itself.

The sizing pass looks for [ and passes control to the regular charac-
ter class parser.  When the charclass is finished, it begins scanning
for [ again.  If it finds ], it assumes it is the end.

That fails with (?[  (?a:(?[  [a]  ]))  ]).  The sizing pass hands
[  [a]  ]... off to the charclass parser, which parses [  [a] and
hands control back to the sizing pass.  It then sees ‘  ]))  ])’,
assumes that the first ]) is the end of the entire construct, so the
main regexp parser sees the parenthesis following and dies.

If we change the sizing pass to look for ?[ we can simply record the
depth (depth++) and then when we see ] decrement the depth or exist
the loop if it is zero.
[perl #24482] Fix sort and require to treat CORE:: as keyword
Stop using PL_sortstash

Originally, the value of PL_sortstash was used to determine whether
PL_firstgv and PL_secondgv (which point to *a and *b in the current
package) needed to be updated (involving symbol lookup).  PL_sortstash
would contain the last package sorted in.  If PL_sortstash did not
point to the current stash, then they would be updated, along with
PL_sortstash.

Sort was made reëntrant in 2000 in commit 8e664e1028b.  This involved
saving and restoring the values of PL_firstgv and PL_secondgv via the
savestack.  The logic introduced by that commit was thus:

+               if (PL_sortstash != stash || !PL_firstgv || !PL_secondgv) {
+                   SAVESPTR(PL_firstgv);
+                   SAVESPTR(PL_secondgv);
+                   PL_firstgv = gv_fetchpv("a", TRUE, SVt_PV);
+                   PL_secondgv = gv_fetchpv("b", TRUE, SVt_PV);
+                   PL_sortstash = stash;
+               }

PL_firstgv and PL_secondgv would be null if no sort were already hap-
pening, causing this block to be executed.  For a nested sort, this
would only be executed if the nested sort were in a different package
from the outer sort.

Because the value of PL_sortstash was not being restored, this block
would not trigger the second time the outer sort called the inner sort
(in a different package).  This was bug #36430 (a duplicate of #7063).

This was fixed in commit 9850bf21fc4e, which did not explain anything
in its commit message.  A preliminary version of the patch was submit-
ted for review in <20051026173901.GA3105@rpc142.cs.man.ac.uk>, which
mentions that the patch fixes bug #36430.

It fixed the bug by localising the value of PL_sortstash, causing the
if() condition to become redundant, so that was removed.

Now, it happened that that if() condition was the only place that
PL_sortstash was used.  So if we are going to localise PL_firstgv
and PL_secondgv unconditionally when sorting, PL_sortstash serves
no purpose.

While I could restore the if() condition and leave the localisation of
PL_sortstash in place, that would only benefit code that does nested
sort calls in the same package, which is rare, and the resulting
speed-up is barely measurable.

PL_sortstash is referenced by some CPAN modules, so I am taking
the cautious route of leaving it in for now, though the core
doesn’t use it.
[perl #117941] Handle vivification crashing w/freed stash

open’s handle vivification could crash if the current stash was freed,
so check before passing a freed stash to gv_init.
[perl #117941] Blessing into freed current stash

If the current stash has been freed, bless() with one argument will
cause a crash when the object’s ‘stash’ is accessed.  Simply disallow-
ing this is the easiest fix.
[perl #117941] eval crashes when current stash is freed
perldiag: typo
[perl #117941] reset crashes when current stash is freed
add 1 to SvGROW under COW (and fix svleak.t)

the new COW scheme uses SvPVX(sv)[SvLEN(sv)-1] (if spare)
to store the COW reference count. If this byte isn't spare, the string is
copied rather than COWed.  So, when built under the new COW, allocate one
more byte than asked for in sv_grow(), to make it likely this byte is
always spare: and thus make more strings COW-able. If the new size is a
big power of two, don't bother: we assume the caller wanted a nice 2^N
sized block and will be annoyed at getting 2^N+1 or more.

Note that sv_grow() already rounds up. For example: formerly, strings of
length 1..15 were allocated 16 bytes, 16..31 allocated 32 bytes, etc
(usually allowing +1 for trailing \0).

Now its 1..14 => 16, 15..30 => 32 etc.

As a side-effect, this should fix a bizarre occasionally failing svleak.t
test under COW. This test,

    '"too many errors" from constant overloading returning undef'

basically twice evals some code that is expected to fail. If over the
course of the second eval the total number of allocated SVs grows, then
the test fails. This particular eval uses overload::constant, and that
module has this code:

    "$_[1]" !~ /(^|=)CODE\(0x[0-9a-f]+\)$/

i.e. match against a stringified reference. Now, if it stringifies to a
15-char string (e.g. "CODE(0x1234567)"), then SvCUR is 15 and SvLEN is 16,
and there isn't a spare byte (after allowing for \0) for the COW ref
count, so the string can't be COWed. Now, if during the first eval,
addresses are in the range 0x1000000..0xfffffff, then COW doesn't kick in.
If during the second eval they fall outside this range, COW kicks in, and
a new SV (which is a COW copy of the string) is attached to the regex, for
capture info. This new SV won't be released until the regex is released,
and so appears to be a leak. If COW kicks in during the first eval then
this isn't an issue, as it will just be reused during the second eval.

This was exceedingly difficult to reliably reproduce, as it was heavily
affected by kernel address randomisation (on linux); plus part of the test
file used rand(); plus of course the hash randomisation and perturbation
feature in 5.18.

I eventually cracked it by: tweaking the hash randomisation; hacking the
perl seed code to use an ENV var rather than /dev/urandom; hacking the
perl startup to display the initial system brk(), then when it failed,
hacked it again to set that particular brk().
Improve fileno example

Quoting from the fileno section of this document:

"[...]  If there is no real file descriptor at the OS level, as can
happen with filehandles connected to memory objects via "open" with a
reference for the third argument, -1 is returned."

Update the example to cater for this situation. Thanks to
Niels Thykier for the suggestion.

Bug-Debian: http://bugs.debian.org/706749
podcheck.t: Output fixed problems as passing to-do tests
pp_hot.c: Correct comment

At this point, ob holds the object the reference points to, not the
reference itself.
Flush PL_stashcache on glob-to-glob assignment

Commit dc93d7fb33f6b2093 says this:

    Flush PL_stashcache when assigning a file handle to a typeglob.

    File handles take priority over stashes for method dispatch.
    Assigning a file handle to a typeglob potentially creates a file
    handle where one did not exist before.  As PL_stashcache only con-
    tains entries for names which unambiguously resolve to stashes,
    such a change may mean that PL_stashcache now contains an invalid
    entry.  As it’s hard to work out exactly which entries might be
    affected, simply flush the entire cache and let it rebuild itself.

But it only applied to io-to-glob assignment.  This commit extends it
to glob-to-glob assignment.
File::Spec::Epoc: Small pod clean-up
[perl #89940] File::Spec->tmpdir and env changes

If the environment changes, File::Spec->tmpdir should respect that and
recalculate the temp directory.

The only objection raised in the ticket was that File::Spec is already
accused of being too slow, so removing the cache would not be a good
idea.  So I put in a check to see whether the relevant environment
variables have changed since the last call to tmpdir.
Correct File::Spec POD about tainting and tmpdir

Since version 3.39_01, the taint check has applied before 5.8.0, too.
Increase some File::Spec versions to 3.41