bump version to RC1

Update Module::CoreList for 5.14.3

Finalise perldelta

Includes spelling, syntax and readability fixes

Add 5.17.4 to perlhist

add 5.16.0 sizes and filecounts to perlhist

running and using the output of Porting/perlhist_calculate.pl
has not been done regularly, presumably because I had no idea
that it existed!

add 5.14.0 sizes and filecounts to perlhist

running and using the output of Porting/perlhist_calculate.pl
has not been done regularly, presumably because I had no idea
that it existed!

Bump copyright year, as it's now 2012

Bump the perl version in various places for 5.14.3

Bump versions of Digest and IPC::Open3

Update perldelta for all queued maint-5.14 changes

IPC::Open3::open3(..., '-') broken

IPC::Open3::open3($in, $out, $err, '-') is broken in 5.14.1

Because the old "return 0" used to return to user code now is wrapped inside and eval block.

This patch solves the problem.

Add 5.17.3 to perlhist

PATCH: [perl #101970] /[[:lower:]]/i matches upper case

This bug is a regression in 5.14, in which /[[:lower:]]/i and
/[[:upper:]]/i no longer matched the opposite case.

The fix is to have these use a different table under /i matching, that
includes the correct /i code points.  These tables were already
available, just unused.

regexec.c: Fix "\x{FB01}\x{FB00}" =~ /ff/i

Only the first character of the string was being checked when scanning
for the beginning position of the pattern match.

This was so wrong, it looks like it has to be a regression.  I
experimented a little and did not find any.  I believe (but am not
certain) that a multi-char fold has to be involved.  The the handling of
these was so broken before 5.14 that there very well may not be a
regression.

PATCH: [perl #101710] Regression with /i, latin1 chars.

The root cause of this bug is that it was assuming that a string was in
utf8 when it wasn't, and so was thinking that a byte was a starter byte
that wasn't, so was skipping ahead based on that starter byte.

Close the eval "require $module" security hole in Digest->new($algorithm)

Also the filter was incomplete.

Bug-Debian: http://bugs.debian.org/644108

properly propagate tainted errors

Backport af89892ed and 05a1a0145d by Tony Cook to 5.14

Bug: https://rt.perl.org/rt3/Public/Bug/Display.html?id=111654
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663158

RT 64804: tainting with index() of a constant

Bug: http://rt.perl.org/rt3/Public/Bug/Display.html?id=64804
Bug-Debian: http://bugs.debian.org/291450
Origin: upstream, http://perl5.git.perl.org/perl.git/commit/3b36395d31cf0a2f3a017505cd0ea857a7acb5d1

At compile time, ck_index with a tainted constant set PL_tainted,
which remained on during the rest of compilation, tainting all other
constants.

Fix this by saving and restoring PL_tainted across the call to
fbm_compile, which is what sets PL_tainted.

enable LFS on GNU/Hurd

at the moment, perl is compiled on GNU/Hurd without large file support.
This, other than the lacking of support for files > 2 GB, causes the
failure in the t/op/stat.t test.
The failure in stat.t happens because of the following: when filtering
devices in /dev/* using grep {} with -b/-c, stat fails for large
devices such as /dev/hdX blocks, or /dev/zero chars (this latter case
should be an Hurd-specific issue, but shouldn't matter for this case),
hence the counts done with grep {} and the ones done filtering the
output of `ls' don't match.

The attached patch enables the LFS using the same way used on linux.sh;
about t/op/lfs.t, it gets skipped at the "kernel/fs not configured to
use large files?" check, although it correctly detects sparse files and
(at least by looking at the disk usage) allocates the 5GB (or so) file
created with system() in that test.

Fix hang in ext/POSIX/t/sysconf.t on GNU/Hurd

while compiling perl 5.14.2 on GNU/Hurd, I ran into what it seems a
undefined POSIX behaviour in ext/POSIX/t/sysconf.t.

      my $fd = POSIX::open($fifo, O_RDWR)
      or skip("could not open $fifo ($!)", 3 * @path_consts_fifo);

according to the POSIX open()[1] about O_RDWR,
  The result is undefined if this flag is applied to a FIFO.
.... which is actually our case.
Apparently Linux and *FreeBSD (and maybe also OSes) accept this
behaviour, but on GNU/Hurd this causes the open() call to block
undefinitely. Given there's nothing done with the FIFO if not querying
{,f}pathconf() values, the proposed solution I attached is to change
the opening mode to "O_RDONLY | O_NONBLOCK".

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html

Add GNU/Hurd hints for NDBM_File

currently, there are few tests failing because of a broken NDBM module;
using the same hints as used on Linux (given that apparently the cause
is the same) makes the following tests pass:
  t/op/dbm.t
  cpan/autodie/t/dbmopen.t
  cpan/Memoize/t/errors.t
  cpan/Memoize/t/tie_ndbm.t
  ext/NDBM_File/t/ndbm.t
  lib/AnyDBM_File.t

Dominic Hargreaves adds: Note that the original git commit log [what
you see above] lists some tests which aren't affected in blead.

Improve general GNU hints, needed for GNU/Hurd.

Bug-Debian: http://bugs.debian.org/636609

With minor modifications to add Pino to AUTHORS.

[perl #90122] Make h2ph correctly search gcc include directories

System header conversion with "h2ph -a" is currently broken on Ubuntu
Natty and Oneiric (unless the gcc-multilib package is installed for
backward compatibility), resulting in things like

 # perl -e 'require "syscall.ph"'
 Can't locate asm/unistd.ph in @INC [...]

This happens because Ubuntu has switched to a 'multiarch' setup, see
<https://wiki.ubuntu.com/MultiarchSpec> for details.

The asm subdirectory isn't in $Config{usrinc} anymore: /usr/include/asm
is now /usr/include/x86_64-linux-gnu/asm. (The third component of the
new path varies with the actual architecture.)

gcc --print-search-dirs doesn't really tell anything about where gcc
looks for the include directories, it was just used to find the gcc
internal directory prefix.

Parse the output of "gcc -v -E" instead, and append $Config{usrinc}
for safety. Duplicates shouldn't matter.

The h2ph "-a" switch isn't currently tested automatically, and that
seems nontrivial to do portably. Manual testing was done with

 # mkdir ttt
 # ./perl -Ilib ./utils/h2ph -a -d $(pwd)/ttt syscall.h

The gcc invocation has been tested to work with gcc 4.6, 4.1, and 3.3.

http://bugs.debian.org/625808
https://bugs.launchpad.net/bugs/777903

Make hints/gnu.sh append to $ccflags rather than overriding them

Bug-Debian: http://bugs.debian.org/587901

Don't override possible extra $ccflags values given to Configure
on GNU/Hurd.

import perlhist data for 5.16.1

be_BY.CP1131 is still broken on Mountain Lion

backport perlhist.pod from 5.17.2

import AUTHORS data from blead

[perl #92258] <$fh> hangs on a glob copy

Opening a file handle to \$glob causes assertion failures
(under debugging) or hangs or other erratic behaviour without
debugging. This might even crash in some cases.

It never really worked properly, but it didn’t start hanging
apparently until 5.12.2 and 5.14.0.

Update PerlCheat to 5.14

Prefer the system gcc when searching for libraries such as -lm

40f026236b9959b7 added code to the Linux hints file to use gcc to locate
libraries such as -lm. However, if the user has their own gcc earlier in $PATH
than the system gcc, we don't want its libraries. So try to prefer the system
gcc.

Don't include libutil.h on Linux

All it does is cause warnings on recent systems with that header installed. It's
required for some variants of FreeBSD only.

GNU gcc-4.6.1 revealed a broken system header on HP-UX 11.00

Teach Configure about "procselfexe" on Solaris and NetBSD

Configure would already find /proc/self/exe on NetBSD, where /proc/self is
a symlink to /proc/curproc. However, the revised probe avoids the extra
symlink traversal. Configure did not previously probe for the
relevant path on Solaris, /proc/self/path/a.out

Rename the description of /proc/curproc/file from BSD to FreeBSD, as it seems
that of the "big 3" BSDs, only FreeBSD uses this path.

Based on a patch from Johann 'Myrkraverk' Oskarsson.

In Configure, refactor the test for procselfexe into a loop.

This removes code duplication, and makes it easy to add more variants.
Based on a patch from Johann 'Myrkraverk' Oskarsson.

Correct FreeBSD hints file for FreeBSD 10.0

Perl does not build on FreeBSD 10.0 because some checks in
hints/freebsd.sh think FreeBSD 10 is FreeBSD 1 and therefore enable
behaviour only appropriate for a.out systems.

The below patch was included in the lang/perl5.12 port and fixes its
build. The resulting binaries are also suitable to compile other ports.
I have also verified that this patch applies to lang/perl5.10 and
lang/perl5.14, making them build.

Avoid attacks on sitecustomize by using NUL delimiters to wrap filenames.

Previously the generated code used regular '' strings, which meant that a
crafted pathname containing ' characters could be used to inject code.
Until the previous commit, this was only a problem if building in or
Configuring to install to such a directory. Which, hopefully, would be
"obviously wrong" to anyone capable of building Perl from source.

However, fixing the bug that prevented sitecustomize being subject to
relocatable include now means that for a relocatable pearl, an end-user
controlled path can now reach the sitecusomize code.

Make sitecustomize relocatableinc aware

When -Dusesitecustomize is used with -Duserelocatableinc,
SITELIB_EXP/sitecustomize.pl is not found due to SITELIB_EXP having a
'.../..' relocation path.

This patch refactors the path relocation code from S_incpush() into
S_mayberelocate() so that it can be used in both S_incpush() and in
usesitecustomize's use of SITELIB_EXP.

Enforce Any ~~ Object smartmatch precedence

Add new 5.15.9 entries to pod/perlhist.pod

Copy perlhist.pod from blead to maint-5.14

Create perldelta for 5.14.3

Add 5.14.2 to perlhist

Delete some empty perldelta sections

Fix pod syntax in perldelta

perl5123delta: should have NAME perl5123delta

Remove the RC1 marker

Bump version to RC1

Add 5.14.2-RC1 to perlhist

Update Module::CoreList for 5.14.2

Acknowledgements in perldelta

/aa and \b fail under some utf8 strings

This was due to my failure to realize that this 'if' needed to
be updated when the /aa modifier was added.

Panic with \b and /aa

This was due to my oversight in not fixing this switch statement
to accommodate /aa when it was added.

Note that PERL_GLOBAL_STRUCT is broken

In Glob.xs, use memset() instead of bzero()

3c97495f56fb647c used bzero(), which isn't available on some platforms.

Perldelta for the CPAN updates

Bump CPAN{,::Distribution}::VERSION after MYMETA/configure_requires fixes

Changed read_meta to ignore dynamic_config

Because read_meta is also used to read META.* for configure_requires,
it must not return undef when dynamic_config is true.  Instead,
the caller of read_meta must check dynamic_config when appropriate.

This is an API change, but as this is a new function, I think getting
correct semantics is more important than preserving back compatibility.

configure_requires should only check META

It should not check MYMETA if for some reason configure_requires
is checked again after MYMETA has been created.

This patch adds a regex filter to the check for the meta file.

Perldelta for the CVE-2011-2939 fix

Backport the CVE-2011-2939 fix for Encode

Perldelta for the PerlIO::scalar COW fix

Get PerlIO::scalar to write to COWs

Fix a perldelta pod nit

Perldelta for read-only glob copies

Make it possible to have read-only glob copies

(aka Fun with Hash::Util)

This script gives ‘Modification of a read-only value’:

use Hash::Util lock_value;
*foo::; # autovivify
lock_value %::, foo::::;
*foo:: = [];

So far so good.  That’s to be expected.  But this one crashes:

use Hash::Util lock_value;
$a{h} = *foo;
lock_value %a, h;
$a{h} = [];

Under debugging builds, it gives assertion failures.

Anyone who knows how the flags work will see immediately what’s wrong,
but for the sake of those who don’t:

The SVf_FAKE flag is set on a copy of a typeglob, meaning that assign-
ing something other than a glob to it will overwrite the glob, instead
of writing to one of its slots.

The SVf_FAKE flag on a read-only (SVf_READONLY-flagged) string means
that it’s not actually read-only, but a copy-on-write string.

SVf_READONLY on a glob means that you can’t even assign *through* it.
See the first Hash::Util example above.

The crashing occurs when the two flags are combined.
sv_force_normal_flags assumes that anything marked fake AND read-only
is a copy-on-write string, so it proceeds to gut it, even if it’s
actually just corrupting a glob.

So this commit changes that check to take typeglobs into account.

Fix a skip count in base's t/fields.t

Allow restricted hashes containing COWs to be cleared

Perldelta for deleting COWs in restricted hashes

Allow COW values to be deleted from restricted hashes

I wonder how many other things a604c75 broke....

Perldelta for the tied COW string localisation fix

Stop localised ties from becoming ro when COW

move "garbage collection" glossary entry where it belongs

Add Pau Amma to AUTHORS

Perldelta entry for the utf8::decode COW fix

2nd try: [perl #91834] utf8::decode does not respect copy-on-write

I reverted the first version of this patch because I put the if()
statement before a declaration. I did a revert, rather than a correc-
tion, to make back-porting easier.

perldelta entry for File:Glob / CVE-2011-2728 fix.

Plug segfault in bsd_glob() with unsupported ALTDIRFUNC flag.

First, disable all the unsupported flags just to make sure they aren't
triggering something they shouldn't be.  Also, zero the pglob struct
before passing to bsd_glob(); it contains function pointers, and it's
safest if they are null rather than containing random stack data.

Bug reported by Clément Lecigne <clemun@gmail.com>.

Perldelta for the Carp memory leak fix

[perl #97020] Carp (actually caller) leaking memory

Commit eff7e72c3 (Detect incomplete caller overrides in Carp) used
this little trick for detecting a @DB::args that an overridden
caller() failed to set:

+  @args = \$i; # A sentinal, which no-one else has the address of

But there is a bug in caller().  The first time caller tries to write
to @DB::args, it calls Perl_init_dbargs first.  That function checks
whether @DB::args is AvREAL, in case someone has assigned to it, and
takes appropriate measures.  But caller doesn’t bother calling
Perl_init_dbargs more than once.  So manually-assigned items in
@DB::args would leak, starting with the *second* call to caller.

Commit eff7e72c3 triggered that bug, resulting in a regression in
Carp, in that it started leaking.  eff7e72c3 was backported to 5.12.2
with commit 97705941a4, so in both 5.12 and 5.14 Carp is affected.

This bug (the caller bug, not Carp’s triggering thereof) also affects
any caller overrides that set @DB::args themselves, if there are
alternate calls to the overridden caller and CORE::caller.

This commit fixes that by changing the if (!PL_dbargs) condition
in pp_caller to if (!PL_dbargs || AvREAL(PL_dbargs)).  I.e., if
@args is either uninitialised or AvREAL then call Perl_init_dbargs.
Perl_init_dbargs also has a bug in it, that this fixes: The array not
only needs AvREAL turned off, but also AvREIFY turned on, so that
assignments to it that occur after its initialisation turn AvREAL back
on again.  (In fact, Larry Wall added a comment suggesting this back
in perl 5.000.)

perldelta for 86212507

Perldelta for the unpack "U*" fix

[perl #90160] U* gives ‘U0 mode on an empty string’

This is a regression in 5.10 caused by change 23966/08ca2aa38a29,
which added a bit of faulty logic. It was treating U* in the middle of
a pack template as equivalent to U0, if the input string was empty.

Support gcc-4.x on HP-UX PA-RISC/64

Correct the socketsize. Probably due to big-endian versus
little-endian, this has always worked on Intel CPUs. This
is a very very old problem,  and it has been the reason I
never used gcc-4 on PA-RISC,  because perl would not pass
the test suite in 64bitall.

Noticeable effects of wrong "$socksizetype" are return codes
of 0 (pass) from functions like getpeername (),  but invalid
(or none) data in the returned structures or a return length
of 0 or 256. In the latter case, the length is stored in the
second part of the 64bit long and the 32bit first part is 0.
This might be true on Intel-like machines too, but the tests
will pass, as the significant part of the returned length is
in the first 32bits and a pointer to int will still see that
correct.  Mind that in that case the 32bits after that might
have been overridden => can of worms.

Perldelta for the @INC filter fixes

Follow-up to d34a6664

As Nicholas Clark wrote in
nntp://nntp.perl.org/20110603192458.GZ2604@plum.flirble.org:

> $ valgrind ./perl -Ilib 91880.pl
> ==5542== Memcheck, a memory error detector
...
> I think that the problem is that this code in S_run_user_filter()
>
>  ENTER_with_name("call_filter_sub");
>  SAVEGENERICSV(GvSV(PL_defgv));
>  SAVETMPS;
>  EXTEND(SP, 2);
>
>
> is putting an action on the save stack to write to an address within
> the GP of PL_defgv. However, the perl code run about 10 lines later
> frees up the GP of PL_defgv, so the scope stack now has a dangling
> pointer. 12 lines later at scope exit, the scope stack unwinding
> writes to the pointer, and nasal daemons emerge.

This commit precedes the SAVEGENERICSV with a call to save_gp, to make
sure the GP is not freed (and then a call to GvINTRO_off [set by
save_gp], so that subsequent glob assignments are not implicitly
localised).

This basically emulates what happens with ‘local *_ = \$some_scalar’,
but without the extra intermediate RV.

[perl #91880] $_ refcounting problems in @INC filters

In @INC filters (subs returned by subs in @INC), $_ is localised to a
variable to which the next line of source code is to be assigned. The
function in pp_ctl.c that calls it (S_run_user_filter) has a pointer
to that variable.

Up till now, it was not setting the refcount or localising
$_ properly.

‘undef *_’ inside the sub would destroy the only refcount it
had, leaving a freed sv for toke.c to parse (which would crash,
of course).

In some cases, S_run_user_filter has to created a new variable. In
those cases, it was setting $_ to a mortal variable with the TEMP
flag, but with a refcount of 1, which would result in ‘Attempt to free
unreferenced scalar’ warnings if the $_ were freed by the subroutine.

This commit changes S_run_user_filter to use SAVEGENERICSV, rather
than SAVE_DEFSV, to localise $_, since the former lowers the refcount
on scope exit, while the latter does not. So now I have also made it
increase the refcount after assigning to the now-properly-localised $_
(DEFSV). I also turned off the TEMP flag, to avoid weird side effects
(which were what led me to this bug to begin with).

Create a perldelta for 5.14.2

Preliminary version bump for 5.14.2

disable use of nm on darwin

Testing from 10.5 with Xcode 3 to the latest OS X works with usenm='false' but
not always with usenm='true'
(cherry picked from commit 60a655a1ee05c577268377c1135ffabc34dbff43)

Remove the RC1 marker

A pod nit

typo fix

more perldelta nits

Removing XXX sections from perldelta

Fix pod syntax errors

Documented the most recent cherrypick.

cherry-pick a delta entry from blead

scan_heredoc could reallocate PL_parser->linestr's PV

Since f0e67a1 it was possible the freed buffer may be read from when
parsing a heredoc. This adds a call to lex_grow_linestr to grow the
buffer and ensure the pointers in PL_parser are updated.

The bug is pretty hard to reproduce, hence no test. I'm able to
reproduce it with the following:

  perl -Meverywhere=re,debug -MParams::Util -e1

snapshot perldelta work