Win32 miniperl: delay loading for Winsock, and then remove it

Slim down the image and speed up start up time for Win32 miniperl by
removing Winsock. Also if the build process on Win32 in the future
requires sockets, commenting one line in win32.h will turn sockets back on
for miniperl, but this time with delay loading on VC Perl. The only casulty
of no sockets for Win32 miniperl was figuring out the computer's name in
win32/config_sh.PL. A workaround by using an ENV var was implemented. The
purpose of this commit is to speed up the build process of Perl.

As said in the comment in win32.h, the WIN32_NO_SOCKETS macro is
incomplete in implementation. It is only removed winsock from being linked
in in miniperl, not full Perl. PERL_IMPLICIT_SYS (specifically PerlSock in
win32/perlhost.h) and makedef.pl's hard coded list of win32_* function
exports cause winsock to still be linked in with even with
WIN32_NO_SOCKETS on full perl. Both PERL_IMPLICIT_SYS (win32/perlhost.h)
and makedef.pl would require changes to remove winsock from being linked
in on full perl in the future.
Remove __attribute__malloc__ from MYSWAP functions

These functions are only used when the native sockets functions are not
available, e.g. when building miniperl on Windows following commit
19253ae62c, so gcc's warning about ignoring the __malloc__ attribute here
is not normally seen.

The addition of "a" to these functions in embed.fnc by
commit f54cb97a39 was presumably wrong since none of them actually
allocate any memory (nor did so at the time), so change it to just "R"
(which is implied by the "a" and is still appropriate).
Initial (incomplete) patch to start restoring WinCE build

Subject: RE: status of WinCE Perl port in 2012
From: "Konovalov, Vadim (Vadim)** CTR **" <vadim.konovalov@alcatel-lucent.com>
Date: Tue, 23 Oct 2012 14:26:49 +0200
Message-ID: <35BF8D9716175C43BB9D67CA60CC345E028EE0C899@FRMRSSXCHMBSC2.dc-m.alcatel-lucent.com>
add the 5.16.2 epigraph
add perl5162delta
add perl5.16.2 to perlhist
Stop / $looks_like_block/ from leaking

If an interpolated string looks as though it contains a regexp code
block, the regexp compiler will evaluate it inside qr'...' and then
extract the code blocks from the resulting regexp object.

If it turned out to be a false positive (e.g., "[(?{})]"), then
the code to handle this returned without freeing the temporary reg-
exp object.
Stop run-time regexp blocks from leaking regexps

This was leaking like a sieve: $var = '(?{})'; /stuff$var/;

When a run-time regular expression has code blocks in it,
those are compiled separately inside their own qr thingy (see
S_compile_runtime_code in regcomp.c).

In re_op_compile, the newly-compiled code blocks are stored in
pRExC_state->code_blocks, which is a mallocked array.  That array also
holds reference counts on the regular expressions from which the code
blocks derive their existence.  When the whole regular expression is
compiled, the code blocks are fetched from that array, and the new
regular expression ends up holding a reference count on those code
block’s originating regular expressions.

The reference counts that pRExC_state->code_blocks had were not low-
ered when pRExC_state->code_blocks was freed, except for qr/stuff$var/
(because the qr// would take ownership of those reference counts,
which would be lowered when the outer qr// itself was freed).
Free detritus when croaking with /(?{})$invalid/

This script was leaking:

$ ./miniperl -e 'warn $$; $x = ")"; while( 1){ eval { /(?{})$x/ }; }'

The mallocked array that is allocated before compilation to hold the
code blocks was not being protected properly around the first pass of
compilation.
Don’t leak with /(?{})$invalid_code_block/

This script was leaking:

$ ./perl -Ilib -wMre=eval -e '$x = "(?{+})"; while(1){eval {/(?{})$x/}}'

The mallocked array that is allocated before compilation to hold the
code blocks was not being freed before the syntax error from the inner
pattern ($x) was propagated.
Fix /a++(?{})+$code_block/

This I would expect:

$ perl5.16.0 -wMre=eval -e '$x = "(?{})"; /a++(?{})+$x/x'
(?{})+ matches null string many times in regex; marked by <-- HERE in m/a++(?{})+ <-- HERE (?{})/ at -e line 1.
Use of uninitialized value $_ in pattern match (m//) at -e line 1.

It warns, but it still runs.

This I would not,

$ perl5.17.5 -wMre=eval -e '$x = "(?{})"; /a++(?{})+$x/x'
Nested quantifiers in regex; marked by <-- HERE in m/a++     + <-- HERE (?{})/ at (eval 1) line 1.

were it not for the fact that I know how it works. :-)

To compile the blocks in $x without recompiling the blocks directly
inside /.../, the regexp compiler blanks out the ‘outer’ blocks with
spaces, and compiles qr'a++     +(?{})'x.  But /x can see through
those spaces, resulting in a change in behaviour.  So use under-
scores instead.
test.pl: allow for undefs in eq_hash

It should be possible to compare hashes with undef values without
triggering warnings.
Detect empty git tag in cmpVERSION
Don't leak stderr from 'git describe' in cmpVERSION
Don’t leak when pushing on to read-only array

$ ./miniperl -Ilib -w -e 'warn $$; while(1){eval {push @-, ""}}'

Croak first instead of creating a new element to store in the
array first and letting av_store croak.
Fix $byte_overload .= $utf8 regression

This is a regression from 5.12.

This was probably broken by commit c5aa287237.

#!perl -lCS
{ package o; use overload '""' => sub { $_[0][0] } }

$x = bless[chr 256],o::;
"$x";
$x->[0] = "\xff";
$x.= chr 257;
$x.= chr 257;

use Devel::Peek;
Dump $x;
print $x;
__END__

Output under 5.12.4:

SV = PVIV(0x820604) at 0x825820
  REFCNT = 1
  FLAGS = (POK,pPOK,UTF8)
  IV = 0
  PV = 0x2139d0 "\303\277\304\201\304\201"\0 [UTF8 "\x{ff}\x{101}\x{101}"]
  CUR = 6
  LEN = 16
ÿāā

Output under 5.14.0:

SV = PVIV(0x820604) at 0x826490
  REFCNT = 1
  FLAGS = (POK,pPOK,UTF8)
  IV = 0
  PV = 0x316230 "\303\277\303\204\302\201\304\201"\0 [UTF8 "\x{ff}\x{c4}\x{81}\x{101}"]
  CUR = 8
  LEN = 16
ÿÄā

The UTF8 flag is only meaningful right after stringification.

If the $byte_overload scalar happens to have the flag on from last
time, but string overloading will turn the flag off, then pp_concat
gets confused as to whether it is dealing with bytes or utf8.  It
sees both sides as having the same utf8ness, so it concatenates,
which stringifies the lhs and turns off the flag.  The utf8 sequences
appended end up with no utf8 flag associated with them, the observable
effect being that the rhs is encoded as utf8.

If it weren’t for encoding.pm, we could use sv_catpvn_nomg_maybeutf8
and avoid determining the utf8ness of the lhs beforehand.  But see-
ing that encoding.pm still exists, we have to prevent double overload
stringification the other way, by force-stringification of the target.
concat2.t: Under miniperl only skip one test
Don’t leak when printfing to bad handle under fatal warnings
Don’t leak when printf causes wide warnings
Stop string eval from leaking ops

This was leaking:

$ ./miniperl  -Xe 'warn $$; while(1){eval "ok 8"};'
1915 at -e line 1.
^C

This was not:

$ ./miniperl  -Xe 'warn $$; while(1){eval "sub {ok 8}"};'
1916 at -e line 1.
^C

The sub is successfully taking care of its ops when it is freed.  The
eval is not.

I made the mistake of having the CV relinquish ownership of the op
slab after an eval syntax error.  That’s precisely the situation in
which the ops are likely to leak, and for which the slab allocator was
designed.  Duh.