regexec.c: Move #defines to earlier in the file

They will be used in a later commit earlier.  This also changes the
wording of the comment slightly to give more explanation, since the
context they are now found in is different

Added Sergey Alekseev to AUTHORS

Correct typo in perlreftut

Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>

add lib/File/DosGlob.pm to .gitignore

The master version of the file now lives in ext

Fix missing argument in sprintf in Socket.xs

Shows up as:
  Socket.xs:919:16: warning: more '%' conversions than data arguments [-Wformat]
  Socket.xs:925:16: warning: more '%' conversions than data arguments [-Wformat]

This bumps the version as well.

Silence a warning under clang/asan

This should silence the following warning:

dump.c:459:57: warning: comparison of constant 85 with expression of
   type 'svtype' is always false [-Wtautological-constant-out-of-range-compare]

The warning is a false positive, this code is /meant/ to detect
conditions that should not happen.

Update IO-Compress to CPAN version 2.059

  [DELTA]

  2.059 10 December 2012

      * IO::Compress::Base
        Added "Encode" option.

Add regression tests for split on string of single wordspace or hex20.

For:  RT #116086

perldelta: Add to-do note for hash changes

I don’t have time for this right now, and I might not for two or three
days, so make sure it is not forgotten.

perldelta for glob changes

known_pod_issues.dat: Allow links to Devel::Callsite

perldelta for bb4784f00 (Constant(undef))

perldelta for 67a057d6d8 (charnames crash)

perldelta for 230834321 (renamed stashes; m??; reset)

perldelta for 55b37f1c31 (goto $tied)

perldelta for f5eec17c/#115818

perldelta for 90b58ec9e (deprecate lexical $_)

perldelta for 4e52a9b69 and db9306af4 (local *method=...)

perldelta: 3d460042 fixed more local *ISA bugs

perldelta for 959f7ad7 (local *Detached::method)

perldelta for 978a498e (PL_sub_generation++)

perldelta for 6e1b2de7 (localised glob assignment)

perldelta for cows sawing ampersands

perldelta for de0df3c09/#23180

perldelta for ee0832cea (lexical constant warnings)

perldelta for 4ded55f35 (lexical constants)

perldelta for lexsub warnings

perldelta: Blanket entry for memory leaks

perldelta for f6f93f805 (circular blessings)

perldelta for 2f43ddf1e (sort {undef})

Use SvREFCNT_dec_NN in one place in hv.h

In this instance, we know that av is not null, so no need to check
whether it is

leakfinder.pl: exceptions

Update Unicode-Collate to CPAN version 0.96

  [DELTA]

  0.96  Sat Dec 15 19:43:10 2012
    - special noncharancter tailorings ('highestFFFF' and 'minimalFFFE')
      * some locales are modified for 'highestFFFF': as, bn, fa, gu, hi, hy,
        kn, kok, mr, or, sa, si, si_dict, ta, te, th, ur.
    - U::C::Locale now allows 'entry' to add or override mappings.
    - bug fix: using DUCET through XS wrongly prevented completely ignorable
      characters from tailoring.
    - modified tests: default.t, loc_as.t, loc_bn.t, loc_fa.t, loc_gu.t,
      loc_hi.t, loc_hy.t, loc_kn.t, loc_kok.t, loc_mr.t, loc_or.t, loc_sa.t,
      loc_si.t, loc_sidt.t, loc_ta.t, loc_te.t, loc_test.t, loc_th.t,
      loc_ur.t, nonchar.t in t.

t/op/inc.t: Add descriptions to all tests lacking them.

t/op/grent.t: Provide descriptions for tests lacking them.

t/op/goto.t: Provide descriptions for remaining tests lacking them.

Focus of these descriptions:  Simply enable user to more easily locate tests
in file.

t/op/filetest.t: Provide descriptions for remaining tests lacking them.

t/op/filehandle.t: Provide descriptions for all tests.

Remove misleading inline comment (dupe of comment in t/op/filetest.t).

t/op/each_array.t: Provide descriptions for all tests.

t/op/dor.t: Provide descriptions for tests still lacking them.

t/op/die_unwind.t: Provide descriptions for some tests.

t/op/die_except.t: Add description for each test.

further fix to SvUPGRADE

The change to SvUPGRADE introduced by 463ea2290a54e a few commits ago
to silence a warning with clang, broke g++ builds instead. Here's
a second attempt to keep everyone happy.

Basically it avoids warnings from all of gcc, g++ and clang for the two
constructs

    SvUPGRADE(...);
    (void)SvUPGRADE(...);

But still breaks

    if (!SvUPGRADE(...) { croak(...); }

which I don't care about.

Add diagnostics for PERL_HASH_SEED warning

Use the right warn routine

warn if PERL_HASH_SEED contains an unexpected character

slight update to perldelta for SvUPGRADE

make SvUPGRADE() a statement.

To guote the perldelta entry:

SvUPGRADE() is no longer an expression. Originally this macro (and its
underlying function, sv_upgrade()) were documented as boolean, although
in reality they always croaked on error and never returned false. In 2005
the documentation was updated to specify a void return value, but
SvUPGRADE() was left always returning 1 for backwards compatibility. This
has now been removed, and SvUPGRADE() is now a statement with no return
value.

So this is now a syntax error:

    if (!SvUPGRADE(sv)) { croak(...); }

If you have code like that, simply replace it with

    SvUPGRADE(sv);

More fun escaping dots in tovmsspec.

c1abd561a0a322 avoided the double escaping of dots in filenames,
but failed to copy the dot itself in cases where it was already
escaped.  Plus, when not using extended file specifications and
thus converting the dot to an underscore, we need to make sure
the underscore is not escaped.

And add a test that covers most of these scenarios.  Probably
more tests are needed.

regcomp.c: silence some compiler warnings

ReREFCNT_inc() returns a value, so cast it to void where not used.

Typemap.xs: fix warning under clang

Trivial type issue in croak format

Remove BeOS special-casing from Configure.

Remove the BeOS port.

BeOS was an operating system for personal computers developed by Be Inc,
initially for their BeBox hardware. The OS Haiku was written as an open source
replacement/continuation for BeOS, and its perl port is current and actively
maintained.

The BeOS port has not been updated since 2004.

Note the GDBM_File changes in perldelta.

Eliminate the fifth argument from GDBM_File::TIEHASH.

This was intended to provide control of the callback used by gdbm* functions
in case of fatal errors (such as filesystem problems), but did not work (and
could never have worked). No code on CPAN even attempted to use it. The
callback is now always the previous default, croak.

This eliminates the only used of 'FATALFUNC' in the *DBM modules' type
files, so remove it from all of them.

It also eliminates a cast from a data pointer to a function pointer, which
is not legal C, and rightly upsets pedantic ANSI C compilers. The fact that
there was exactly cast, and only in one direction, gives a clue as to how
likely this was ever to work.

GDBM_File is meant to croak() if the gdbm library has a fatal error.

gdbm_open() takes a fifth argument, for an optional callback function used
to report a fatal error. Since it was added in 5.000, the tied hash wrapper
implemented in GDBM_File.xs has (intended) to default this to croak().
However, the callback expects a function taking a single const char *
argument, whereas croak(const char *pat, ...) has variable arguments.
The code as-was had two bugs

1) The calling ABI on some platforms differs between a (known) variable-
   argument function, and one which takes (known) fixed arguments. As the
   call site knows the pointer is to a function with fixed arguments, the
   calling convention it uses doesn't match what Perl_croak_nocontext()
   expects, which can lead to crashes.
2) A message containing % characters will be interpreted as a printf format.

Both these are fixed by using a small station function as a wrapper, which
takes a single string argument, and passes to croak() a "%s" format string,
followed by the string for the error message.

Add a test for this functionality.

B.xs: silence clang warning

PADOFFSET is unsigned, so checking that it's >= 0 is pointless.

chdir's argument is a directory in DosGlob.t.

It probably doesn't matter anywhere but VMS, but on VMS,
disk:[dir.blead]t (the result of catfile) is an invalid argument to
chdir, but disk:[dir.blead.t] (the result of catdir) is correct.

Sigh. Fix lex.t again

PERL_UNICODE can cause things to happen in a different order
internally.

{Dos,}Glob.xs: Skip freeing during global destruction

See ticket #116064.

File::Glob and ::DosGlob free data associated with a calling op when
that op is freed.

During global destruction, there is no need to do that, as it will be
freed anyway.

Also, during sv_clean_all dMY_CXT can cause us to read freed memory.

Fix occasional failures in svleak.t and DosGlob.t

If the random number of ops happens to be 0 the first time, then we
end up with a false positive, as evaluating '$x+<*>' after '<*>' will
vivify the *x glob.

leakfinder.pl: More exceptions

perl.h: fix signedness warning with clang

'len' arg to my_vsnprintf() is supposed to be Size_t; cast it that way
before testing it.

In DosGlob.xs, add a block around MY_CXT_INIT, as it contains a declaration.

The macro MY_CXT_INIT contains a variable declaration, and xsubpp doesn't
wrap XS BOOT sections within a block, hence code at the start of the BOOT
section may already be after code. Hence wrap MY_CXT_INIT within a block, to
ensure that its initialisation is before any code.

Data::Dumper is at 2.139

Bring Data::Dumper version and changelog up to date with CPAN release

The 2.139 CPAN release just went out. It has the same code that is in
blead now, but it has distribution fixes on top of blead that wouldn't
make sense here. This bumps the version and imports the change log.

perlvar.pod: Slight clarification, typo

better POD for mg_get and SvGROW

SvGROW unconditionally derefs SvANY to check SvLEN. A crash occurs if the
sv is SVt_NULL. Also mg_get uses SvMAGIC which also has the same problem.
Rather than having people finding these properties out by trial and error,
document them. There is no sense in adding type checks since these 2 calls
have been had sv type restrictions since probably day 1 and for
performance reason. Anyone who hit the restrictions would have either
fixed their code immediately, or abandoned using XS. I observed someone
abandoning XS in the field over these undocumented restrictions.

Really fix t/op/lex.t

I *thought* I had run the tests after making commit 6d70c68615.

[Merge] hash assignment fixes and speedup

In <CAMOxC8vCaYk3GD0NRH=jxGmNKu+bmKTrYKR2nsrgU6Wei+xmYQ@mail.gmail.com>
Ruslan Zakirov wrote:
> I've finished my work on pp_aassign. I find it ready for review.
> Each commit has plenty of details, but here is short description:
>
>     * scalar(%h = (1,1,1,1)) returns 4, not 2
>     * warn on ($s,%h) = (1,{}) as on (%h) = ({})
>     * (%h = (1)) in list context returns (1, $h{1})
>       instead of (1)
>     * return of (%h = (1,1,1)) in list context was incorrect
>     * in list context returned keys was aliased to RHS scalars
>       of aassign
>     * returned list from ((%h, @a) = ...), hash on LHS followed by
>       array or hash, was incorrect
>     * implemented right to left algorithm for not magic hash assignment
>       in scalar and void context
>     * use less mortals is list context
>     * in list context hash assignment return keys aliased to RHS
>       when it's ok (it's not LVALUE context)

pp_hot.c: Comments to clarify pp_aassign

[The committer took these from <201210240658.q9O6w1u25266@crypt.org>
and turned them into a patch.]

hashassign.t: Suppress oddball warnings

hashassign.t: Test undef explicitly

thereby eliminating uninit warnings

Copy keys for aassign in lvalue sub

Checking LVRET (which pp_aassign does, as of a few commits ago)
has no effect if OPpMAYBE_LVSUB is not set on the op.  This com-
mit changes op.c:op_lvalue_flags to set this flag on aassign ops.

This makes sub:lvalue{%h=($x,$x)} behave correctly if the return
values of the sub are assigned to ($x is unmodfied).

hash argument is not used anymore in do_oddball

rename arguments to make more clear what function takes

pp_hot.c:pp_aassign: mortalise variable only if we have to

This affects the hash-assignment path.

Don’t mortalise the value to protect it from a magical key making the
hv_store_ent call die, as that could unduly extend the mortals stack.

Instead, copy the key if it is magical.

Based on a patch by Ruslan Zakirov.

don't create a copy of keys if it's not LVALUE context

Making another copy slows things down. We can avoid it
if aassign is not expected to return LVALUEs.

refactor aassign

move populating stack with return values. Place it
into main loop right after we stored values.

This allow us to delete special if blocks for
hash/array on LHS followed by other hash/array.

Also, clearing HV out of ENTER/LEAVE block is bad -
segfaults in corner cases.

Don't use goto for odd elements case.

store undef on stack for odd case. we can avoid NULL
checks in the loop and use assert like array assignment
does.

use SvSETMAGIC rather than repeate what it means.

for array and hash assignment "while (relem <= SP)" loop
at the end was always empty. Put it into else branch.

ary/hash/firsthashelem should be set only once

Only once for first hash or array, otherwise
(%h,@a) = ... assignment returns wrong results
for duplicates and/or number of elements on RHS.

we need duplicates counter only in list context

test return values of aassign with various elements on LHS

* hash on LHS followed by array, other hash or scalar,
  for example (%h, @a) = (...);

* above with normal RHS, with duplicates, odd elements
  and combination.

* inspect elements returned by aassign for lvaluedness

* assign doesn't return elements that were just cleared

hash assign in list context should copy key as well

if we don't then returned keys are aliases for RHS
values and can result in unexpected changes

make sure hash assignment is proper lvalue

fix issues in hash assignment with odd elements

1) unify code path of processing odd case with regular
loop that process pairs. fixes memory leak when key
is magic and dies on fetch.

2) in list context put undef that we added to compensate
odd elements into returned values, so (%h = (1))
returns (1, $h{1}) rather than (1). This is documented
in perldoc perlop:

    a list assignment in list context produces the list
    of lvalues assigned to.

Here can be a dispute, but:

* that key without value on RHS is still assigned with
  undef
* consider (%h = (1,2,3,4,5,6,3)). Returning (1,2,3,undef,5,6)
  is much easier than (1,2,5,6,3).
* order of returned elements follows cases with even number
  of elements on RHS and duplicates

3) hash assignment with duplicates and odd elements on
RHS was returning wrong results in list context.
Now (%h = (1,1,1)) returns (1,$h{1}).

test hash assignment with odd elements for leaks

if key scalar is tied and dies on fetch then hash assignment
is leaking a key value

warn on ($s,%h) = (1,{}) as on %h = {}

Latter results in "Reference found where even-sized list expected"
message while former produces "Reference found where even-sized list
expected". Quite inconsistent.

test "Odd number of elements in hash assignment"

scalar(%h = (1,1,1,1)) should return 4, not 2

perldoc perlop says:

    a list assignment in scalar context returns the number of elements
    produced by the expression on the right hand side of the assignment

Behaviour was changed as side effect of
ca65944e8ff8fff6e36ea7476ba807be16cfe2a9 where goal was to fix
return value in list context.

t/op/lex.t: Fix test

It was a copied-and-pasted repeat of another test, both of which I
added in commit 67a057d6d.  I know it used to crash and the commit
fixed it, as I tested it at the time with one-liners.

regexec.c: silence compiler warning

The code was mixing signed and unsigned types

Glob.xs: PL_opfreehook is an interpreter variable

Hence, there is no need to lock a mutex; also storing the old value
in a C static is bad.  It needs to be in a spot local to the current
interpreter, which MY_CXT provides.

DosGlob: Don’t leak when caller’s op tree is freed

File::DosGlob keeps its own hash of arrays of file names.  Each array
corresponds to one call site.  When iteration finishes, it deletes
the array.  But if iteration never finishes, and the op at the call
site is freed, the array remains.  So eval "scalar<*>" will cause a
memory leak under the scope of ‘use File::DosGlob "glob"’.

We already have a mechanism for hooking the freeing of ops.  So
File::DosGlob can use that.

This is similar to 11ddfebc6e which fixed up File::Glob, but that com-
mit mistakenly used a C static for storing the old hook, even though
PL_opfreehook is an interpreter variable, not a global.  (The next
commit will fix that.)

Update Digest-SHA to CPAN version 5.80

  [DELTA]

  5.80  Mon Dec 10 14:15:26 MST 2012
    - obtained noticeable speedup on Intel/gcc
        -- by setting -O1 and -fomit-frame-pointer
        -- SHA-1 about 63% faster, SHA-2 improves 11-20%

perldelta for 34213185

I considered more detail here, but the discussion in the ticket
covers it.

fix warning in PmopSTASH_set()

In the threaded version of PmopSTASH_set(), the assigned value is a
PADOFFSET, not a pointer; so use 0 rather than NULL for the default value.

This keeps clang happy.

Stop DynaLoader.t from unload File::Glob

File::Glob now sets PL_opfreehook.  That means that if we unload it we
will leave PL_opfreehook pointing to an invalid address, resulting in
a crash when ops are freed.

I didn’t catch this because the tests are skipped on darwin.  They
don’t actually need to be, at least under recent versions, so I modi-
fied the skip code.

Fix problems with -Dr during global destruction

$ cat foo
my $x = '(?{1})';
BEGIN { $^H |= 0x00200000 } # lightweight "use re 'eval'"
"a" =~ /a$_/ for $x;

If I run this under PERL_DESTRUCT_LEVEL=2 with the -Dr flag on a non-
threaded build, the output ends with this:

 during global destruction.
 during global destruction.
 during global destruction.
 during global destruction.
 during global destruction.
Attempt to free temp prematurely: SV 0x822610 during global destruction.
Attempt to free temp prematurely: SV 0x802340 during global destruction.
Attempt to free temp prematurely: SV 0x8222d0 during global destruction.
Attempt to free temp prematurely: SV 0x822490 during global destruction.
Attempt to free temp prematurely: SV 0x8224f0 during global destruction.
Scalars leaked: 5

And sometimes I even get assertion failures.  (I suspect hash random-
isation gives me the inconsistent results.)

t/re/recompile.t happened to trigger this bug, producing noisy output.
Since the assertion failures were in sub-processes, the tests passed
anyway.  In this commit I have changed the test to check the status of
the sub-processes, too, before reporting a pass.

This bug appears to have started happening in v5.17.0-424-gd24ca0c,
but I don’t know why.  I suspect it was a latent bug waiting
to happen.

During global destruction, all objects are freed, the main stash is
freed, and then various SVs in interpreter variables are also freed.
Finally, if PERL_DESTRUCT_LEVEL is set, there is one last sweep of all
remaining SVs.  It is during that sweep that this bug occurs.

When the -Dr flag is present, freeing a regular expression causes the
${^RE_DEBUG_FLAGS} flags variable to be looked up.

Symbol lookup can trigger the ‘Global symbol requires package name’
error (which becomes a warning here, due to the way pp_ctl.c:qerror
works).  The code that produces that error assumes that if there is
no stash then the preceding code has detected an attempted stricture
violation.

The preceding code actually tries to provide PL_defstash (aka %main::)
as the stash to look in, since this is a punctuation variable.  But
PL_defstash has been set to null.

The logic that no stash equals a stricture violation is there-
fore faulty.

The attempt to output that error message uses a temporary scalar which
is placed on the mortals stack.  Freeing of the items on the mortals
stack happens before this SV sweep, and not during or afterwards, so
the SV sweep ends up trying to free those mortals itself.  There is a
check in sv_free2, enabled under debugging builds, to see whether the
SV is on the mortals stacking.  If it is, a warning is emitted and the
SV is not freed.

My initial attempt at fixing this was to try to avoid putting a mortal
on the stack in this case.  The code in question doesn’t actually need
to use the mortals stack, since Perl_mess isn’t going to croak, so it
can free the SV itself.  That takes care of the ‘Attempt to free temp
prematurely’ warnings and the final ‘Scalars leaked’.  It doesn’t
solve the ‘during global destruction’ message, but I decided to leave
it in place anyway, since creating an SV and freeing it is a little
more efficient that creating it, pushing it on to the mortals stack,
and having FREETMPS free it later.

That ‘during global destruction’ message is supposed to say ‘Global
symbol...’, but diagnostic messages during global destruction use the
same SV, so it’s not suprising that it gets stomped on before it makes
its way to qerror.  I’m not sure where it gets stomped on, but it’s
not relevant; we need to get rid of the message altogether.

The final solution is to skip the ‘Global symbol...’ error altogether
while sv_clean_all (the final SV sweep) is being called, which we can
detect based on whether PL_in_clean_all is set.

Don’t leak when partly iterated glob op is freed

File::Glob keeps its own hash of arrays of file names.  Each array corresponds to one call site.  When iteration finishes, it deletes
the array.  But if iteration never finishes, and the op at the call
site is freed, the array remains.  So eval "scalar<*>" will cause a
memory leak.

We already have a mechanism for hooking the freeing of ops.  So
File::Glob can use that.

Increase $File::Glob::VERSION to 1.19

Remove the second param to tryAMAGICunTARGETlist

This parameter is no longer used.  Its value is always 0.