win32/win32sck.c: dont close() a freed socket os handle

This patch is in RT as [perl #120091] but also fixes [perl #118059].

Because the MS C lib, doesn't support sockets natively, Perl uses
open_osfhandle, to wrap a socket into CRT fd. Sockets handles must be
closed with closesocket, not CloseHandle (which CRT close calls).
Undefined behavior will happen otherwise according to MS. Swap the now
closed socket handle in the CRT to INVALID_HANDLE_VALUE. The CRT will
not call CloseHandle on INVALID_HANDLE_VALUE and returns success if it
sees INVALID_HANDLE_VALUE. CloseHandle will never be called on a socket
handle with this patch.

In #118059, a race condition was reported, where accept() failed with
ENOTSOCK, when a psuedofork was done, and connection from the child fake
perl process to parent fake perl process was done. The race condition's
effects occur inside the user mode code in mswsock.dll!_WSPAccept in the
parent perl, which winds up having a kernel handle of an unknown type
in it that is invalid. The invalid handle is passed to kernel calls, which
fail, because the handle is invalid, and the error is translated to
ENOTSOCK.  The exact mechanism of the bug and 100% reproducabilty of the
race were never established, since mswsock.dll is closed source.

Another benefit of this patch is making it easier to use C debuggers on
a Win32 Perl because of less debugger-only bad handle exceptions
(NtGlobalFlag FLG_ENABLE_HANDLE_EXCEPTIONS/0xC0000008 STATUS_INVALID_HANDLE).

This commit reverts parts of commit 9b1f18150a
"Get rid of PERL_MSVCRT_READFIX" and parts of commit 46e77f1118
"Don't use the PERL_MSVCRT_READFIX when using VC++ 7.x onwards." and
contains additional changes not found in those 2 commits. The method for
selecting the definition of struct ioinfo isn't perfect. It will break if
VC > 6 is changed to use the older msvcrt.dll. For some versions of the
CRT, like 2005/8.0, it is impossible to know the definition of ioinfo
struct at C compile time, since the struct increased in size a number of
times with higher build numbers of v8.0 CRT. SxS and security updates make
that same perl binary will run with different v8.0 CRTs at different times.
For the case when ioinfo can not be hard coded, introduce
WIN32_DYN_IOINFO_SIZE. With WIN32_DYN_IOINFO_SIZE, the size of the ioinfo
struct is determined on Perl process startup using _mize. Since VC 2013
is a brand new product at the time of this patch, even though its struct
is known, and 2008 through 2012 have been stable so far, don't assume at
this time 2013's ioinfo will be stable. Therefore, VC 2003 and older
(including Mingw's v6.0), 2008 to 2012, are hard coded. 2013 is a candidate
one day to be hard coded. VC 2005 can never be hard coded.

All non-WIN32_DYN_IOINFO_SIZE compilers will work with
WIN32_DYN_IOINFO_SIZE. Non-WIN32_DYN_IOINFO_SIZE mode is simply more
efficient.

For future compatibility concerns, 3 forms of protection are offered.
If __pioinfo isn't exported anymore, the Perl build will break. In
WIN32_DYN_IOINFO_SIZE mode, if __pioinfo isn't heap memory anymore or the
start of a memory block, the runtime panic will happen. In with and without
WIN32_DYN_IOINFO_SIZE, only on a DEBUGGING build, the handle returned by
CRT's _get_osfhandle, which is the authentic handle in the CRT, is compared
to the handle found by accessing the ioinfo struct directly. If they don't
match, the handle swapping code is broken and the assert fails.

Revise fake bool build advice from f789f6a4bdb.

The suggestions from that Craig Berry fellow were only half-baked.

Undefined lex sub used as inherited method crashes

Thanks to misuse of CvGV.

$ perl5.19.5 -XMfeature=:all -e 'my sub foo {} undef &foo; *UNIVERSAL::bar = \&foo; main->bar()'
Segmentation fault: 11

When deciding under which name to autoload the sub, we can’t assume
CvGV(that_sub) is a GV, as it may be null.

remove redundant Zero() from JMPENV_BOOTSTRAP

In commit 14dd3ad8c9 , a 3 NULL assigns were converted to a Zero() for what
I guess was an optimization. This also caused the large je_buf to be
zeroed even though je_buf was uninit before. At that time, JMPENV had
2 extra members that don't exist anymore. The 2 extra members in JMPENV
were removed in commit 766f891612 . The comment about je_throw was made
obsolete in commit 766f891612 so rework it.

One function call free NULL assign is faster than a memset() call.
je_buf is 0x40 bytes long on 32 bit VC2003 Win32 Perl. No need to zero it
since je_buf is never read unless je_prev is not NULL. Also there is no
need to zero the last 2 members je_ret and je_mustcatch since they are
immediatley assigned to. Move PL_top_env assignment to near je_prev so
compiler tries to optimize better since je_prev is the start of the struct
and hopefully will calculate the pointer once.

Also put some poisoning in case JMPENV gets new members in the future.
To conditionally poison in a macro, PERL_POISON_EXPR is being introduced
instead of 2 different definitions of JMPENV_BOOTSTRAP.

remove unneeded dependency on Test::More 0.98 (RT#88531)

shared.pm: Consistent spaces after dots

threads::shared: Remove redundant description just added

In commit fd013656aac I moved the documentation for the two warnings
that threads::shared produces from perldiag.pod to shared.pm, without
rewording anything.

These two warnings had almost identical descriptions, and--I found
later--basically repeat some of the documentation of the cond_signal
function, so point to that description in the warnings section and
avoid repeating things.

Increase $threads::shared::VERSION to 1.45

Move threads::shared warnings from perldiag to shared.pm

following the precedent set by threads.pm.

toke.c:S_tokeq: add comment

toke.c:S_tokeq: remove dead code

The argument passed to tokeq is always a plain string owning its own
buffer.  I checked all the callers.

This code has been like this since perl 5.000.

Remove ancient threads diagnostics from perldiag

for several reasons:
• The wording has changed, so nobody is using these entries anyway.
• The perldiag entries are clearly not being maintained.
• The threads module has its own list of diagnostics.
• The actual wording depends on the version of the threads module
  installed, not the version of perl.

perlhack.pod: consistent spaces after dots

perllexwarn: consistent spaces after dots

‘Attempt to bless into a ref’ with stale method caches

As of v5.16.0-81-g234df27, SvAMAGIC has only meant potentially over-
loaded.  When method changes occur, the flag is turned on.  When over-
loading tables are calculated (the first time overloading is used),
the flag is turned off if it turns out there is no overloading.

At the time I did that, I assumed that all uses of SvAMAGIC were to
avoid the inefficient code path for non-overloaded objects.  What I
did not notice at the time was that SvAMAGIC is used in pp_bless to
determine whether an object used as a class name should be exempt from
‘Attempt to bless into a reference’.

Hence, the bizarre result:

$ ./perl -Ilib -e 'sub foo{} bless [], bless []'
$ ./perl -Ilib -e 'bless [], bless []'
Attempt to bless into a reference at -e line 1.

This commit makes both die consistently, as they did in 5.16.

[perl #119809] Disallow bless($ref, $tied_ref)

There is no reason tied (or otherwise magical variables like $/)
should be exempt from the ‘Attempt to bless into a reference’ error.

bless.t: More explicit test

Not only does this prevent us from accidentally producing the wrong
error, it also makes it easy to grep and see that this error is
tested.

Use tabs consistently in AUTHORS

Documentation Patches from Tom Hukins

Reported as [perl #120406].

tr is documented in perlop's "Quote-Like Operators" section, not its
"Quote and Quote-like Operators" section.

Don't describe PerlIO as "new".

perllexwarn: typo, pod syntax

Add a note that users of FATAL warnings are at risk during upgrades

Apparently it isn't obvious to all of our users that use of FATAL
warnings means that peoples code may break when they upgrade due
to the introduction of new warnings. Accordingly we document that
the use of FATAL warnings is entirely at the users risk, and that
we do not and will not consider the introduction of a warning as
an incompatible change, and that in particular the use of features
which are discouraged, unspecified, or whatnot may in the future
trigger new warnings, and thus under FATAL warnings break their code.

Introduce PERL_BOOL_AS_CHAR define

This allows compilers that do support real booleans (C++ or anything
with stdbool.h) to emulate those that don’t.

See ticket #120314.

This patch incorporates suggestions from Craig Berry.

perlre: Expand and clarify /x and (?# comment)

This pod omitted some of the details about how comments in regexes work.
I had to do some experimentation to find some of the answers.
I believe this clarifies things as well.

Fix broken qr/ \N* /x

Under /x, the parsing was skipping the character following a \N (when
meaning [^\n]).  In fact the parse pointer was already pointing to the
first non-white-space character, so advancing skipped the character.
That character could be the beginning of a (?#...) comment, all of which
should be skipped.

regcomp.c: Clarify some comments

pad.h: Correct PadlistMAX docs

They have been wrong since I added them.

Increase $B::Deparse::VERSION to 1.24

[perl #119807] Deparse s//\(3)/e in a way that does not warn

Code that does not warn should not be deparsed in a way that warns.
s//\3/e produces a warning about misuse of \3 where $3 is meant.
s//\(3)/e compiles to the same thing and produces no such warning.
So B::Deparse should parenthesize references to numbers in the rhs
of a substitution.

Eliminate ‘Can't use \1 to mean $1’ false positives

We need to check that the quote-like operator we are parsing is a sub-
stitution (not just any quote-like operator) and that we are parsing
the right-hand side.

enable LTO/LTCG/WPO for most Visual Cs

All Win32 Visual C compilers except for VC 6/_MSC_VER == 1200 support LTCG.
LTCG generates slightly smaller and slightly faster binaries.

[perl #120408] fix dist/ExtUtils-ParseXS/t/002-more.t

the plan is fragile 29 = 2 + 2 + 25

Signed-off-by: Francois Perrad <francois.perrad@gadz.org>

'$! = EACCESS; require ...' could fail

When require is checking against a particular entry in @INC, it stats the
potential pathname, and does various checks like skipping if it's a
directory. In this case the stat succeeds, so $! is left unchanged.
Later however, pp_require() checks for $! being EACCES. So if $! was
already set before the require, this could influence require's behaviour.

Don’t record cop address for unbreakable lines

The cop (control op) address for each statement is recorded in
${"_<$file"}[$line] so that breakpoints set on that line will flag the
op for that statement.

Then, at run time, pp_dbstate checks to see whether the op is flagged
as having a breakpoint, and calls the debugger if so.

Statements that are not breakable are nextstate, rather than dbstate
ops, and pp_nextstate ignores the flag on the op.

In some instances, the cop address was being recorded for nextstate
ops.  This would happen in preamble code (e.g., the PERL5DB envi-
ronment variable or the -M switch) and when $^P contained 0x400
but not 0x02.

Recording the cop address for a nextstate op serves no purpose and is
a waste of CPU cycles.

[perl #119799] Set breakpoints without *DB::dbline

The elements of the %{"_<..."} hashes (where ‘...’ is the filename),
whose keys are line numbers, are used to set breakpoints on the given
lines.  The corresponding @{"_<..."} array contains the actual lines
of source code.

%{"_<..."} actually acts on the array of lines that @DB::dbline is
aliased to.  The assumption is that *DB::dbline = *{"_<..."} will have
taken place first.  Hence, all %{"_<..."} hashes are the same, when it
comes to writing to keys.

It is more useful for each %{"_<..."} hash to set breakpoints on its
corresponding file’s lines regardless of whether @DB::dbline has been
aliased, so that is what this commit does.

Each hash’s mg_obj pointer in its dbfile magic now points to the
array, and magic_setdbline uses it instead of PL_DBline.

pp.c:pp_undef: Don’t vivify the scalar slot

When PERL_DONT_CREATE_GVSV is defined, perl generally does not vivify
the scalar slot in every GV.  But it hides that implementation detail
by vivifying it when *foo{SCALAR} is accessed.

undef(*foo) was one exception to this.  It vivified the scalar in
the scalar slot regardless of whether PERL_DONT_CREATE_GVSV was
defined.

Until recently, it was not safe to remove this exception, because a
typeglob with no scalar could be a candidate for downgrading (see
gv.c:gv_try_downgrade), causing global pointers like PL_DBgv to point
to freed SVs.  Recent commits have fixed all those cases, so this
is now safe.

Make PL_incgv fully refcounted

It was only reference-counted in the main thread:

$ ./perl -Ilib -e 'delete $::{INC}; eval q"my $foo : bar"'
$ ./perl -Ilib -e 'use threads; async {delete $::{INC}; eval q"my $foo : bar"}->join'
Assertion failed: (SvTYPE(_gvgp) == SVt_PVGV || SvTYPE(_gvgp) == SVt_PVLV), function S_apply_attrs_my, file op.c, line 2600.
Abort trap: 6

pat.t: suppress warning

perl.h: Remove ERRHV

It has been unused by the core since 5.6.0 (98eae8f58) and is
unused on CPAN.

Don’t assume *^R has a scalar

$ perl -e '*^R = *foo; /(?{})/'
Segmentation fault: 11

[perl #54044] Make PL_replgv refcounted

Otherwise one can free it and make perl crash:

$ perl -e 'delete $::{"\cR"}; //'
Segmentation fault: 11

It crashes because PL_replgv now points to a freed SV which has no GV
slots, so GvSV on it fails.

gv:gv_try_downgrade: Leave PL_last_in_gv alone

gv_try_downgrade exists to remove globs and subs that were (possibly
temporarily) vivified by bareword lookup.  It is called whenever a
gvop is freed and its gv looks like a candidate for downgrading.  That
means it applies, not only to potential sub calls, but also to *foo
and *bar.  gv_try_downgrade may delete a glob from the stash alto-
gether if it is empty.  So eval "*foo if 0" may delete the *foo glob.

PL_last_in_gv is the internal variable underlying ${^LAST_FH}.  If
gv_try_downgrade deletes the last-read handle, then ${^LAST_FH}
will become undefined, whereas eval "*foo if 0" is not supposed to
do anything:

$ ./miniperl -le 'readline *{"foo"}; warn ${^LAST_FH}; eval "*foo if 0"; warn ${^LAST_FH}'
GLOB(0x7f8f5a0052a0) at -e line 1.
Warning: something's wrong at -e line 1.

Make PL_argvgv refcounted

Otherwise one can free it and cause assertion failures when other
things do SvREFCNT_inc on a freed scalar:

$ ./miniperl -le 'undef *x; delete $::{ARGV}; $x++; eval "BEGIN{undef *x} readline"'
Assertion failed: (SvTYPE(sv) != (svtype)SVTYPEMASK), function Perl_sv_clear, file sv.c, line 6215.
Abort trap: 6

gv:gv_try_downgrade: Leave PL_stderrgv alone

gv_try_downgrade exists to remove globs and subs that were (possibly
temporarily) vivified by bareword lookup.  It is called whenever a
gvop is freed and its gv looks like a candidate for downgrading.  That
means it applies, not only to potential sub calls, but also to *foo
and *bar.  gv_try_downgrade may delete a glob from the stash alto-
gether if it is empty.  So eval "*foo if 0" may delete the *foo glob.

PL_stderrgv is a shortcut variable that points to *STDERR.  When
PL_stderrgv is null, the real stderr is used as a fallback.

If gv_try_downgrade deletes *STDERR (which causes PL_stderrgv to be
cleared), it can could the behaviour, which is not supposed to happen.
It doesn’t actually delete *STDERR right now, because undef() vivifies
the scalar slot, disqualifying the glob from downgrading.

If we change undef not to vivify the scalar slot (I plan to soon, and
this commit prepares for it), then this is what would happen without
this commit:

$ perl -le 'close *{"STDERR"}; undef *{"STDERR"}; eval "*STDERR if 0"; *{"STDERR"} = *STDOUT{IO}; warn'
$ perl -le 'close *{"STDERR"}; undef *{"STDERR"}; *{"STDERR"} = *STDOUT{IO}; warn'
Warning: something's wrong at -e line 1.

Notice how the first one-liner (with the eval) produces no output.

When deleting via hek, pass the computed hash value

In those cases where the hash key comes from a hek, we already have a
computed hash value, so pass that to hv_common.

The easiest way to accomplish this is to add a new macro.

Make PL_hintgv refcounted

Otherwise one can free it (by deleting the *^H glob) and
cause a crash:

$ perl -e 'delete $::{"\cH"}; ${^OPEN}=foo'
Segmentation fault: 11

That happens because PL_hintgv points to a freed scalar, and
GvHV(PL_hintgv) ends up trying to access nonexistent fields.

Don’t create %@ on startup

This hash has been unused since perl-5.005_02-2093-g98eae8f:

commit 98eae8f585b9800849b5e5482e2d405f21bab67e
Author: Gurusamy Sarathy <gsar@cpan.org>
Date:   Fri Oct 8 10:26:15 1999 +0000

    remove kludgey duplicate background error avoidance (caused
    "leaks"; %@ wasn't even user-visible under -Dusethreads);
    only repeats of most recent error are now avoided

    p4raw-id: //depot/perl@4316

[perl #119811] Remove %DB::lsub

Under the debugger (the -d switch), if there is a DB::sub subroutine,
then %DB::lsub gets autovivified during a call to an lvalue sub.  That
hash is never used.  The code for vivifying the *DB::lsub glob was
copied from *DB::sub when lsub was added, and *DB::sub does have a
hash (%DB::sub), but *DB::lsub doesn’t need one.

Make PL_envgv refcounted

Otherwise deleting $::{ENV} will make chdir crash:

$ perl -e 'delete $::{ENV}; chdir'
Segmentation fault: 11

This happens because PL_envgv points to a freed SV and GvHV(PL_envgv)
tries to access nonexistent fields.

Make PL_firstgv and PL_secondgv refcounted

Otherwise freeing *a or *b in a sort block will result in a crash:

$ perl -e '@_=sort { delete $::{a}; 3 } 1..3'
Segmentation fault: 11

Update Socket to CPAN version 2.013

  [DELTA]

2.013   2031/10/28 00:49:43
        [BUGFIXES]
         * Unit-test bugfixes for VMS (RT89766):
            + Need to pass protocol => IPPROTO_TCP to avoid SCTP as well
            + Perform AI_NUMERICHOST test against non-"localhost"
            + May have to set NI_NUMERICSERV flag if it fails without

Update HTTP-Tiny to CPAN version 0.037

  [DELTA]

0.037     2013-10-28 13:26:21 America/New_York

    [FIXED]

    - Basic authentication in the URL is now unescaped before being encoded
      into the authentication header

    [DOCUMENTED]

    - Added HTTP::Tiny::UA to SEE ALSO and suggested it as the appropriate
      place for new features

[perl #120398] skip t/porting/extrefs.t when cross-compiling

The toolchain is not installed on the target when cross-compiling.
So, this test must be skipped.
(same problem as RT#119769)

Signed-off-by: Francois Perrad <francois.perrad@gadz.org>

perlfunc: clarify hash "modify while iterating"

[perl #120308]

5.18.0 introduced a new warning:

   Use of each() on hash after insertion without resetting hash iterator
   results in undefined behavior

which resulted in a debate as to whether the behaviour should also be
*documented* as as "undefined". This commit updates the documentation to
say that it is "unspecified".

getnameinfo, getaddrinfo, and inet_xxx fix-ups for configure.com.

This is mostly a very belated follow-up to d7fba2bf7c68c, but in
the case of inet_aton, is a stupendously belated follow-up to
570bb66edbdc8.

Don't make bool an int on VMS.

The special case has been there since 61bb59065bf1b12edab3, most
likely because the VMS C++ compiler, like a lot of other C++
compilers in the 1990s implemented a bool as an int, and making
the type in C compatible seemed like a good idea.  But no C++
compiler that's likely to build Perl on VMS has a bool type that
occupies more than one byte now, so remove the special case.  We're
unlikely to even see this code since we've had stdbool.h since
DEC C 6.4, released in 2001.

Update Unicode-Collate to CPAN version 1.00

  [DELTA]

1.00  Sun Oct 27 13:22:17 2013
    - When a subroutine by 'overrideOut' taking a out-of-range value and
      returning undef, now the value is treated as if it were U+FFFD.
      * 0.99 wrongly calculates implicit weights based on out-of-range values.
    - Assertion using unpack 'U' is added. If not only pack('U') but also
      unpack('U') of CORE:: don't work as expected, this module will die.

Update Term-Cap to CPAN version 1.15

  [DELTA]

1.15 Sat Oct 26 21:28:29 BST 2013
      - meta data patch from David Steinbrunner
      - Change email in metadata

1.14 Sat Oct 26 19:20:03 BST 2013
      - Update versions everywhere
      - Change email address and add the github location

1.13 Sat Oct 26 19:08:27 BST 2013
      -  Bring everything up to date with all patches from RT
      - Sync version with core

Don’t let gv.c:gv_try_downgrade touch PL_statgv

PL_statgv remembers the handle last used by stat, for the sake of -T _
and -B _.  If a glob is freed when PL_statgv points to it, PL_statgv
is set to null.

gv_try_downgrade exists to remove globs and subs that were (possibly
temporarily) vivified by bareword lookup.  It is called whenever a
gvop is freed and its gv looks like a candidate for downgrading.  That
means it applies, not only to potential sub calls, but also to *foo
and *bar.  gv_try_downgrade may delete a glob from the stash alto-
gether if it is empty.  So eval "*foo if 0" may delete the *foo glob.

If PL_statgv is pointing to *foo, then eval "*foo if 0" may change the
behaviour, which is not supposed to happen:

$ ./perl -Ilib -le 'stat *{"foo"}; -T _; print $!; -T _; print $!'
Bad file descriptor
Bad file descriptor
$ ./perl -Ilib -le 'stat *{"foo"}; -T _; print $!; eval "*foo if 0"; -T _; print $!'
Bad file descriptor
No such file or directory

Make PL_DBgv and other db interp vars refcounted

$ PERL5DB=1 perl -de '*DB::DB = sub {} if 0; sub DB::DB{}'
No DB::DB routine defined at -e line 1.

When the ‘if’ gets folded and *DB::DB is freed, it triggers
gv_try_downgrade, causing $DB::{DB} to be deleted and PL_DBgv to point
to a freed SV.  A higher refcount would prevent gv_try_downgrade from
touching it.

perl.c: Avoid redundant gv_AVadd and GvAVn

We don’t need to call gv_AVadd if follewed by GvAVn, which itself
calls gv_AVadd when the AV is null.

Also, we don’t need to keep checking whether GvAV(PL_argvgv) is still
defined (via GvAVn with the final n) when pushing on to it.

This code goes back at least to perl 5 alpha 2.

gv:gv_add_by_type: Don’t check @ISA when not vivifying

I added the code (in 986d39eeb4) to magicalise @ISA when vivifying it
via @{*ISA}.  But we don’t need to do that every time gv_add_by_type
is called, just when it is autovivifying.

Add op_other to B::Concise -debug output for LOGOPs

Regen META.{yml,json}

(If t/porting/regen.t fails without this regeneration, why doesn’t
‘make regen’ do this?)

Add Kevin Falcone to AUTHORS

No longer point to rt.perl.org/perlbug/ as a landing page

We'll use the homepage of rt.perl.org instead, as it's much more likely
to get text updates.

update RTSERVER

This didn't work properly as is (because of the redirect from
http://rt.perl.org/rt3/ to https://rt.perl.org/rt3/) but at least it'll
work if someone tries it going forward.

Allow newer bug URLs on rt.perl.org

Fixup rt.perl.org/rt3 => rt.perl.org

These links all would redirect properly, but give out the top URL.

Update AutoLoader to CPAN version 5.74

  [DELTA]

5.74  Fri Oct 25 19:08 2013
  - Makefile.PL: Set installdirs to "site" on Perl >= 5.12

Make sure truncated in-memory files have trailing null

Just spotted this....

If the target scalar contains something already, then setting SvCUR to
0 is not sufficient.

t/porting/dual-life.t: Another exception

In parallel testing, it might fail on files like
cpan/Module-Metadata/MB-9dzadSLU/Simple/bin/simple.plx.

Increase PerlIO::scalar::VERSION to 0.18

Better fix for #119529

<$fh> used to loop if $fh was opened to an in-memory handle containing
a reference.

Commit 552908b174 fixed the loop by forcing a reference to a string
when the handle was created.  It did not take into account that the
reference might be read-only.  It was also insufficient, in that
the target scalar could be set to a reference after the handle
was created.

The real reason it was looping was that the code for returning and
setting the size of the buffer was not handling non-PVs properly
(unless they were globs, which were special-cased).  It might return
0, and it might not, depending on what the internal SV field hap-
pened to hold.

This caused looping under 5.12 and onwards, but even in 5.10 <$fh>
returned nothing.

In this case, deleting code makes things just work.

Reverting the hunk from 552908b174 stops appending to refs from work-
ing, so I tweaked PerlIOScalar_pushed to fix that (which also reduced
the amount of code).

Remove some unnecessary Makefile.PLs from cpan/ and ext/

These modules all work with the default Makefile.PL written by make_ext.pl.

(There are more Makefile.PLs in dist/ that could be removed too, but the
general policy with dist/ is to leave such files in place to make it easier
to roll CPAN releases from the blead source, which is canonical.)

Silence some Win32 compiler warnings

These get rid of some "possible loss of data" warnings

PATCH [perl #120314]: fold_grind.t spews tons of warnings

It turns out that fixing the compiler warnings about possible loss of data
(by adding casts) silences these warnings.

Propagate lvalue context to && and ||

I did this for the last statement in an lvalue sub (and the argument
to ‘return’ in an lvalue sub) in commit 2ec7f6f2428.

It turns out that it needs to apply in other lvaluish contexts, too:

$ ./perl -Ilib -le 'for($a||$b){$_++} print $b'
1
$ ./perl -Ilib -le 'for(pos $a || pos $b){$_++} print pos $b'
Modification of a read-only value attempted at -e line 1.

If I can assign to $b through this construct, then why not pos?

pp_hot.c:pp_rv2av: Remove superfluous SPAGAIN

Commit perl-5.8.0-9908-g5e17dd7, in March of 2007, added a SPAGAIN
here to account for the stack shifting when hv_scalar calls tied
hashes’ SCALAR method.

It was never necessary, because commit perl-5.8.0-3008-ga3bcc51,
which added hv_scalar and magic_scalarpack in December of 2003, made
magic_scalarpack push a new stack, protecting the old one.

rv2hv does not use its TARG

rv2hv has had a TARG since perl 5.000, but it has not used it since
hv_scalar was added in perl-5.8.0-3008-ga3bcc51.

This commit removes it, saving a tiny bit of space in the pad.

Update Package-Constants to CPAN version 0.04

  [DELTA]

0.04    Thu Oct 24 20:34:00 BST 2013
=================================================
* Update Makefile.PL to add repository et al
* Install into site if >= v5.12.0
* Add use deprecate due to core scheduled removal

Schedule Package::Constants for removal from core

Update Archive-Tar to CPAN version 1.96

  [DELTA]

1.96  24/10/2013
- integrate Package::Constants into Constant module
  and remove requirement on it.

1.94  24/10/2013
- install into site if >= 5.012

1.93_02 22/10/2013 (XLAT)
- [rt.cpan.org #78030] symlinks resolution on MSWin32

Restore prev. behaviour of @a||... in lv sub

$ perl5.18.1 -lwe 'my @a;  sub i:lvalue {@a||@b} @a=1; (i())=3'
Name "main::b" used only once: possible typo at -e line 1.
Useless assignment to a temporary at -e line 1.

Bleadperl:

$ ./perl -Ilib -lwe 'my @a; sub i:lvalue {@a||@b} @a=1; (i())=3'
Name "main::b" used only once: possible typo at -e line 1.
Can't return array to lvalue scalar context at -e line 1.

I accidentally changed it in commit 2ec7f6f242 by propagating the
lvalue context.  This commit changes it back by only flagging the
rv2av op as being in an lvalue sub if it is not already flagged as
being in scalar context.

The old behaviour was inconsistent, and this commit does restore it
(see the tests), but resolving that discrepancy is for a future commit
(if I ever get to it).

In any case, ‘Can't return array to lvalue scalar context’ is wrong.

Fix bare blocks in lvalue subs

If a bare block is the last thing in an lvalue sub, OP_LEAVELOOP needs
to propagate lvalue context and handle returned arrays properly, just
as OP_LEAVE has done since yesterday.

This is a follow-up to 2ec7f6f24289.  This came up in ticket #119797.

Make the details array in universal.c static

Otherwise we can have linking problems when a global ‘details’ symbol
is defined elsewhere.  (That happened to me with an XS module.)

Increase $B::Concise::VERSION to 0.991

I don’t know, is it time for version 1 yet?

[perl #119797] Fix if/else in lvalue sub

When if/else/unless is the last thing in an lvalue sub, the lvalue
context is not always propagated properly and scope exit tries to
copy things, including arrays, resulting in ‘Bizarre copy of ARRAY’.

This commit fixes the bizarre copy by flagging any leave op that is
part of an lvalue sub’s return sequence, using the OPpLEAVE flag added
for this purpose in the previous commit.  Then pp_leave uses that flag
to avoid copying return values, but protects them via the mortals
stack just like pp_leavesublv (actually pp_ctl.c:S_return_lvalues).

For ‘if’ and ‘unless’ without ‘else’, the lvalue context was not being
propagated, resulting in arrays’ getting flattened despite the lvalue
context.  op_lvalue_flags in op.c needed to handle AND and OR ops,
which ‘if’ and ‘unless’ compile to, to make this work.

Add OPpLVALUE flag

This flag will be used by the next commit.

Increase $bignum::VERSION to 0.37

Add Marc Simpson to AUTHORS

Minor bignum POD fix (capitalisation).

bump Tie::StdHandle version

after recent fixes

Tie::StdHandle::WRITE: handle offset

the WRITE method was ignoring its offset argument.

Tie::StdHandle appends extra copies of $\ to output

[perl #120202]

The following code demonstrates the problem:

    use Tie::Handle;

    my $out = do { no warnings 'once'; \ local *HANDLE };
    tie *$out, 'Tie::StdHandle', '>&', \ *STDOUT or die;

    $\ = "haha\n";
    print $out "hihi\n";

which prints

    hihi
    haha
    haha

The string in $\ has been added twice, once explicitly by
Tie::Handle::PRINT and another time implicitly by the use of
(CORE::) print in Tie::StdHandle::WRITE.

The bug also affects the use of say() with tied handles where a spurious
newline is added by the same effect.

[ test added by davem ]

stdhandle.t: unlink the right file.

It writes to "afile", but initially deleted "afile.new" if it already
existed.

stdhandle.t: convert to use Test::More

print "ok 13\n" is *so* 1990's.

Make B/Deparse handle unicode regexes

[perl #120182]
the precomp B::OP method was returning a non-UTF8 string even if the
regex was utf8

correct POD for SvIsCOW, it returns a U32

refactor sv_add_backref

-don't assign NULL twice to var mg, seen in machine code
-use sv_magicext to get MAGIC * instead of a 2nd call to mg_find, less
 passes through the linked list is faster
-move the mg_flags MGf_REFCOUNTED statement to before av, to reduce scope
 of liveness for var mg, it is never used again in the function
-av can not be null since it was just created, use
 SvREFCNT_inc_simple_void_NN
-on a tsv, that is being upgraded to be an AV backref holder, call
 av_extend only once with the correct slice count based on whether tsv was
 a SV backref holder or not previously
-since on a newly AV backref tsv, the number of backrefs will only be 1 or
 2, and if we made an AV type backref holder, doing the SV type
 optimization is now impossible, so don't check av for NULL when we know
 it wont be if we just made the AV, and don't do the bounds check and 2nd
 av_extend either since the AV is new and under our control
-if tsv is already an AV type backref, the AV can have 1 to infinity
 elements so do the bounds check and av_extend as before

It is intentional that on the new AV type holder branch, that after
"av_extend(av, *svp ? 2 : 1);" there are no further function calls in the
execution path until the return.

Add support for building with Visual C++ 2013

Two tests (t/io/fs.t and cpan/HTTP-Tiny/t/110_mirror.t) fail on my system,
currently in Daylight Saving Time, both due to times written/read by
utime()/stat() being off by one hour...

Not sure what the issue is yet, but I've reproduced it in this C program:

#include <stdio.h>
#include <sys/stat.h>
#include <sys/utime.h>
void main(void) {
  struct _utimbuf ut;
  struct _stat st;
  time_t t;
  t = 760060800;
  printf("Setting: %ld\n", t);
  ut.actime = t;
  ut.modtime = t;
  if (_utime("test.c", &ut) == -1) {
    perror("_utime failed\n");
    return;
  }
  if (_stat("test.c", &st) != 0) {
    perror("_stat failed\n");
    return;
  }
  printf("  atime: %ld\n", st.st_atime);
  printf("  mtime: %ld\n", st.st_mtime);
}

which outputs

Setting: 760060800
  atime: 760057200
  mtime: 760057200

with VC++ 2013, instead of

Setting: 760060800
  atime: 760060800
  mtime: 760060800

like Visual C++ 6.0 through 2012 all do.