sv.c apidocs: SV_NOSTEAL, not NOSTEAL

NOSTEAL is nonexistent.  While abbreviating constants may be fine for
comments, using such forms in API documentation may be less than
helpful.

constant.pm: Consistent spaces after dots in pod

It was inconsistent throughout.

Increase $constant::VERSION to 1.29

Compile-time checking for %$obj{"key"} under ‘use fields’

This single line of code also gives us shared hash key optimisa-
tions for free.

Fix bad read in gp_free introduced by 4571f4a72

4571f4a72 attempted to fix this:

$ ./perl -Ilib -e 'sub foo{} bless \&foo; DESTROY { undef *foo } undef *foo'
Attempt to free unreferenced glob pointers, Perl interpreter: 0x7fd6a3803200 at -e line 1.

by lowering the refcount of the gp only after freeing the contents.

But what was missing was a check at the end to make sure the refcount
was not already 0.

In fact, that can’t work either, as, if the refcount has gone down
to 0 while freeing the contents of the gp, we will be reading
freed memory.

In an attempt to implement what my half-baked idea was meant to do,
I thought of incrementing the reference count before freeing the
entries, and then checking it afterwards, but that would cause an
‘undef *foo’ during that to null the gp slot of the gv and replace it
with a new one.  In the mean time, gp_free is only freeing the old gp
and the new gp will leak when it sets GvGP to 0.

I thought of detaching the gp from the gv completely before freeing
its entries, but most code doesn’t expect to see typeglobs with no gp.
GvSV will crash.

I nearly concluded that the only approach I could use was to revert
4571f4a72 and simply extirpate that warning.  As far as I can tell, it
only comes up with recursive gp_free calls.  However, in those cases,
simply returning will cause a memory leak, as pp_undef will give the
gv a new gp, and the outer gp_free call, when it finishes, will set
the gv’s gp slot to null, overwriting what pp_undef put there (a vari-
ation of the leak above).

So, the final solution is for gp_free to re-read the GvGP value each
time it loops, freeing entries.  The reference count will continue to
be decremented at the end of the function, as in 4571f4a72.  That will
prevent any bad reads.  If pp_undef has reallocated the gp in the mean
time, we will simply start using the new one.  We need an extra refer-
ence count check at the end, in case a destructor does glob assignment
and causes the gp to be shared.

Ideally this should fix the recent build errors.  (See
<20131113045538.GA18816@mars.tony.develop-help.com>.)  I tried it
under valgrind on dromedary both before and after the patch, and the
bad reads went away.

Compliance: Mixed declarations not allowed in some pre-C99 compilers

Dynaloader: fix build issue

My commit from yesterday, 860b3d937d9b004a7de4b684765ab75006c71f00,
inadvertently included c99-ish mixed declarations and code.

NO C99 comments, please!

[PATCH] Upgrade to threads::shared 1.45

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

Opcode: fix 'null argument' warning

HvNAME_get() can return NULL, and strNE() wants non-null args.

[
As a side note: on debugging builds this line

    if (strNE(HvNAME_get(hv),"main")) {

macro-expands into an 18,000 character line (!) due to the fact that
HvNAME_get() is quite a big expansion under debugging, and strNE expands to
strlen, which under gcc expands to a huge macro (which is mainly lots of
different compile-time alternatives depending on which of its args are
constants), that references its args several times.
]

IO.xs: fix compiler warning

PerlIO_unread() returns SSize_t, although from its sparse documentation
it doesn't seem that it would ever return a negative value. So cast away
the 'comparison between signed and unsigned integer' warning.

File::Glob: fix warnings and non-\0-ended strings

The lower levels of File::Glob expect null-terminated strings, while
the higher levels do s = SvPV(sv,len) and pass the len. Ease the impedance
mismatch by ensuring that s[len] is always \0. Most perl SVs will already
have that \0 anyway, so in practice this hasn't been an issue.

It also ignores the utf8-ness of the string. I've kept that as-is (too big
a can of works to open for now), but I've fixed the 'is_utf8 var not used'
warning and added an XXX comment instead.

File::Glob: silence some compiler warnings

In bsd_glob.c, there are nested set of functions glob0(), glob1() etc,
which among their parameters pass a pointer to a compiled pattern, and also
to its end. It turns out the end pointer isn't usually used, since the
pattern is usually scanned for BG_EOS instead. Also, glob3() is
passed two pattern ranges, both within the same pattern, and both with
the same pointer to the end of the pattern buffer. Since both end pointers
are the same, eliminate one of them. This removed an unused var compiler
warning. Use the remaining end pointer in the glob*() functions to add
assertions that we haven't fallen off the end of the buffer.

Finally, ARG_MAX may be signed.

podcheck: Remove workaround no longer needed

The bug this worked around has been fixed by
406e3fef7f4bebd2003087bce74d22303981ac48

Devel::Peek: fix some compiler warnings

arybase: silence some compiler warnings

some of the static functions in  ptable.h are unused. It looks
like ptable.h has been written to be more general-purpose and reusable,
but at the moment its only used in one place, so '#if 0' the unused
functions for now, to shut up the compiler..

File-DosGlob: silence some compiler warnings

B: silence some compiler warnings

The renaming of the 'form' arg to 'format' is due to form being #deffed to
Perl_form() or similar.

Some of the unused vars were due to things like BmPREVIOUS() being #deffed
to 0 in recent builds.

The pad ones were due to the PADOFFSET type being used to index a pad
*list*, not a pad - that's SSize_t.

DynaLoader: silence some compiler warnings

silence some compiler warnings

Actually, most of this commit is adding (void) to various function returns
where we know its ok to ignore the return value. This doesn't actually
silence the -Wunused-result warning (thanks a bundle gcc), but at least
it marks our intentions.

fix definition of GvFILEGV()

It was:

    #define GvFILE(gv)   (GvFILE_HEK(gv) ? HEK_KEY(GvFILE_HEK(gv)) : NULL)
    #define GvFILEGV(gv) (gv_fetchfile(GvFILE(gv)))

which is a problem, since gv_fetchfile() doesn't accept a non-null
argument. Change it so that the (cond ? foo : NULL) thing is outside
gv_fetchfile(). This is all a bit academic since GvFILE_HEK should never
be null, but it at least it shuts up a compiler warning.

Update Test-Harness to CPAN version 3.30

  [DELTA]

3.30    2013-11-12
        - Fix missing parent prereq in META.{yml,json} and NotBuild.PL
          (Dagfinn Ilmari Mannsåker, #89650)
        - Respect PERL5LIB in tainting source handler test (Dagfinn Ilmari Mannsåker,
          Leon Timmermans)
        - Use base instead of parent:

          This dist is used for testing all other modules, so it should avoid
          having any non-core prerequisites.  Having parent as a prereq leads to a
          circular dependency of parent -> Test::More -> Test::Harness. (Graham Knop)
        - Various POD fixes (Nathan Gary Glenn)
        - Don't localize all of %ENV in harness.t (Craig Berry)
        - Give TAP::Harness::Beyond a unique NAME (Leon Timmermans)

Another perldelta to-do

perldelta for 93860275f3

perldelta for 84971b2da4

perldelta for 2186f87343

perldelta for a96df64385

Another perldelta to-do

that I don’t understand well enough to explain

perldelta for 6a5c965b9

perldelta for 952ad5fef9, 6041797116, a93a1bfd14

perldelta for ea238638ab

perldelta for 069abe75ae, ae2c6838c9 and fcea1f7ab3

perldelta for 7274b33cb1

perldelta for ca58dfd9e0

Update Module-Build to CPAN version 0.4200

  [DELTA]

0.4200 - Tue Nov 12 12:39:25 CET 2013

  - Released 0.40_11 as 0.4200

0.40_11 - Wed Nov  6 12:46:59 CET 2013

  [BUG FIXES]

  - Do not set provides in metadata if no_index is set [Leon Timmermans]

0.40_10 - Tue Nov  5 12:11:37 CET 2013

  [BUG FIXES]

  - Lowercase license in fallback logic [Leon Timmermans]

0.40_09 - Tue Nov  5 00:13:11 CET 2013

  [ENHANCEMENTS]

  - Converted to using Meta 2.0

perldelta for 71323522ef

perldelta for 0e706dd460 and e6307ed02e

perldelta for c41f466f88

perldelta: potential to-do item

I don’t understand this commit enough to know whether it warranst
inclusion, let alone to write a description for it.

perldelta for 8bfda0d7d5

perldelta for c7ea825dcc

perldelta for 8d9dd4b93f

perldelta for f789f6a4bd

perldelta for 8ee4c05d16

perldelta for 9f125c4af0

perldelta for e37958c391

perldelta for b2da7ead68

perldelta for 43e4250a61

perldelta for 4a2b275c6c

perldelta for 2be08ad105

perldelta for f03015cd13 and preceding commits

f03015cd13
475b1e904e
722fa0e997
4639d557ab
cf93a474d4
8465ba4524

perldelta for af230ad61a

perldelta for 8cece9139ae

perldelta for a854082c1d

perldelta for 5a2bc23bfe

perldelta: put things in the right sections

I could have sworn I had them in the right place.  I think git’s
ability to merge changes can be fooled.

perldelta for 2e73d70e52

perldelta for 2ec7f6f242 and a373464fd6

perldelta for 3c41103a26

perldelta for 2cf89ea7ef

perldelta for fea7fb25a

perldelta for 46879fadd0

perldelta for fcbc518d7a

In newATTRSUB, clear glob slot before lowering refcount.

(Actually in its subroutine, S_already_defined.)

Otherwise, when newATTRSUB redefines a sub, the previous sub’s DESTROY
can see the same sub still in the typeglob, but without a reference
count, so *typeglob = sub {} frees the sub currently in $_[0].

$ perl5.18.1 -le '
    sub foo{}
    bless \&foo;
    DESTROY {
        print "before: $_[0]"; *foo=sub{}; print "after: $_[0]"
    }
    eval "sub foo{}";
'
before: main=CODE(0x7fa88382d6d8)
before: main=CODE(0x7fa88382d6d8)
after: main=CODE(0x7fa88382d6d8)
after: UNKNOWN(0x7fa88382d6d8)

In newXS, clear glob slot before lowering refcount.

Otherwise, when newXS redefines a sub, the previous sub’s DESTROY can
see the same sub still in the typeglob, but without a reference count,
so *typeglob = sub {} frees the sub currently in $_[0].

$ perl5.18.1 -le '
    sub re::regmust{}
    bless \&re::regmust;
    DESTROY {
        print "before: $_[0]"; *re::regmust=sub{}; print "after: $_[0]"
    }
    require re;
'
before: main=CODE(0x7ff7eb02d6d8)
before: main=CODE(0x7ff7eb02d6d8)
after: main=CODE(0x7ff7eb02d6d8)
after: UNKNOWN(0x7ff7eb02d6d8)

Undeffing a gv in DESTROY triggered by undeffing the same gv

$ ./perl -Ilib -e 'sub foo{} bless \&foo; DESTROY { undef *foo } undef *foo'
Attempt to free unreferenced glob pointers, Perl interpreter: 0x7fd6a3803200 at -e line 1.

Lowering the reference count on the glob pointer only after freeing
the contents fixes this.

Simplify code for deparsing socketpair

Instead of fixing a typo programmatically, just spell it correctly to
begin with.  This should make things just slightly faster.

check existence of headers and libs for WinCE in Makefile.ce

Macro LIBC was used since day 1 of WinCE port (commit e1caacb4fd ), but
never before defined. On Desktop Win32 Perl, LIBC is msvcrt.lib, so fix
corelibc/msvcrt to be LIBC and not part of CELIBS. Then use LIBC in a
sanity check. Sanity checks will give an error message, vs running the
C compiler and geting cryptic messages about unknown .hs and random
missing symbols.

fix chop formats with non PV vars

[perl #119847],  [perl #119849], [perl #119851]

Strange vars like ties, overloads, or stringified refs (and in recent
perls, pure NOK vars) would generally do the wrong thing in formats
when the var is treated as a string and repeatedly chopped, as in
^<<<~~ and similar. This would manifest itself in infinite loops, utf8
errors etc. A recent change that stopped a stringified NOK getting
converted into a POK made the same badness happen for plain NVs too.

This commit contains two main fixes. First, the chopping was done
using sv_chop(), which only worked on POK strings. If its !POK, we now do
sv_setpvn() instead, which is less efficient, but will ensure the right
thing is always done.

Secondly, we make sure that the sv is accessed only once per cycle,
doing s = SvPV(sv, len) or similar. After that, all access is done only
via s and len. One place was using SvPVX(sv), and several places
were using the sv for utf8<->byte length conversions, such as
sv_pos_b2u().

It turns out that all the complex utf8 handling could be enormously
simplified. Since the code that needed to do utf8/byte length conversions
already scanned the string looking for suitable split points (such as
spaces or \n or \r), it was easiest to include any utf8 processing in the
same loop - i.e. incrementing s by UTF8SKIP(s) each time, but incrementing
the character count by 1.

The original diagnosis and reporting of this issue was done by Nicholas
Clark, who also supplied most of the tests.

pp_formline(): document switch cases

The individual ops (such as FF_END) of the format bytecode are documented
in form.h; appned those descriptive texts also to the individual 'case
FF_END:' lines in pp_formline, to make navigation easier. Also ensure
there's a blank line before each 'case'.

No functional changes.

Synology support now more explicit

Johan Vromans tested the changes on DS413. The changes I added before
are more Synology specific (though perhaps not only appropriate for
Synology) but at least wider than just armv5tel

[perl #75156] fix the return value and bits for removing a closed fh

[perl #75156] tests for deleting a closed handle from IO::Select

fix multi-eval of Perl_custom_op_xop in XopENTRY

Commit 1830b3d9c8 introduced a flaw where XopENTRY calls
Perl_custom_op_xop twice to retrieve the same XOP *. This is inefficient
and causes extra machine code. Since I found no CPAN or upstream=blead
usage of Perl_custom_op_xop, and its previous docs say it isn't 100%
public, it is being converted to a macro.

Most usage of Perl_custom_op_xop is to conditionally fetch a member of the
XOP struct, which was previously implemented by XopENTRY. Move the XopENTRY
logic and picking defaults to an expanded version of Perl_custom_op_xop.
The union allows Perl_custom_op_get_field to return its result in 1
register, since the union is similar to a void * or IV, but with the
machine code overhead of casting, if any, being done in the callee
(Perl_custom_op_get_field), not the caller. Perl_custom_op_get_field can
also return the XOP * without looking inside it to implement
Perl_custom_op_xop.

XopENTRYCUSTOM is a wrapper around Perl_custom_op_get_field with
XopENTRY-like usage.

XopENTRY is used by the OP_* macros, which are heavily used (but rarely
called, since custom ops are rare) by Perl lang warnings system. The
vararg warning arguments are usually evaluted no matter if the warning
will be printed to STDERR or not. Since some people like to ignore warnings
or run no strict; and warnings branches are frequent in pp_*, it is
beneficial to make the OP_* macros smaller in machine code. The design
of Perl_custom_op_get_field supports these goals.

This commit does not pass judgement on Ben Morrow's unclear public or
private API designation of Perl_custom_op_xop, and whether
Perl_custom_op_xop should deprecated and removed from public API. It was
trivial to leave a form of Perl_custom_op_xop in the new design.

XOPe enums are identical to XOPf constants so no conversion has to be
done between the field selector parameter and the field flag to test
in machine code.

ASSUME and NOT_REACHED are being introduced. The closest to the 2
previously was "assert(0)". Perl has not used ASSUME or CC specific
versions of it before. Clang, GCC >= 4.5, and Visual C are supported. For
completeness, ARMCC's __promise was added, but Perl is not known to have
any support for ARMCC by this commiter.

This patch is part of perl #115032.

Update Unicode-Collate to CPAN version 1.02

  [DELTA]

1.02  Sun Nov 10 18:39:37 2013
    - POD: fix [rt.cpan.org #90170] about iso-8859-1 letters in pod.
      E<> is used for the compatibility with perl 5.6.1 and possibly EBCDIC.
    - 1.01 forgot to increase the version number of CJK/Korean.pm.
    - modified tests: cjkrange.t, compatui.t, hangtype.t, illegal.t,
      loc_ja.t, loc_ta.t, overcjk0.t, overcjk1.t, view.t in t.

op.c: Factor out common entersub-building code

This same incantation occurs four times, though the readpipe variant
was slightly different.  The only difference was the lack of a scalar
flag on a null op, which makes no difference:

-           <1> ex-rv2cv sK ->-
5              <$> gv(*require) s ->6

-           <1> ex-rv2cv K ->-
5              <$> gv(*readpipe) s ->6

So I did not include the scalar() call, as it was unnecessary.  Also,
I changed op_append_elem to newLISTOP, since the former calls the lat-
ter anyway in these cases.

Fix deparsing of glob(my $x) and CORE::glob

A git bisect run like this:

$ ../perl.git/Porting/bisect.pl --start=v5.12.0 --end=v5.18.0 -e 'use B::Deparse; die if new B::Deparse->coderef2text(sub{glob my $x}) =~ /</'

points to v5.13.8-86-gd1bea3d as being the commit that cause it to
output <my $x>.

But my local 5.14.4 installation still outputs glob(my $x), so I am
not sure which commit is responsible.  I suspect it changed multi-
ple times.

In any case, B::Deparse was expecting the argument to pp_glob always
to be a string, which is certainly not guaranteed.

This commit also causes CORE::glob to be deparsed correctly.  glob is
one of those oddities like require that gets only half-overridden by
overrides.  In this particular case the built-in pp_glob is still
used, but takes a different code path depending on whether it was pre-
fixed with CORE::.  So, while glob is a strong keyword, it needs to be
treated as a weak one for deparsing purposes.

Stop open fh, ">>", \$undef from warning

$ ./perl t/TEST ../cpan/Test-Simple/t/subtest/bail_out.t
t/../cpan/Test-Simple/t/subtest/bail_out ... Use of uninitialized value in open at /Users/sprout/Perl/perl.git-copy/cpan/Test-Simple/../../lib/Test/Builder.pm line 1895.
ok
All tests successful.
u=0.01  s=0.00  cu=0.09  cs=0.01  scripts=1  tests=2

Notice the uninitialized value.

$ ./perl -Ilib -Mwarnings=uninitialized -e 'open $fh, ">>", \$x'
Use of uninitialized value $x in open at -e line 1.
$ perl5.18.1 -Mwarnings=uninitialized -e 'open $fh, ">>", \$x'

I caused that in v5.19.5-44-g5a2bc23:

$ ../perl.git/Porting/bisect.pl --start=045071eede --end=blead -e 'use warnings FATAL=>"uninitialized"; open $fh, ">>", \$x'
...
5a2bc23bfe5dc60ff957cb44ffaa57668d56d238 is the first bad commit
commit 5a2bc23bfe5dc60ff957cb44ffaa57668d56d238
Author: Father Chrysostomos <sprout@cpan.org>
Date:   Fri Oct 25 06:15:30 2013 -0700

    Better fix for #119529

op.c: Remove unused var

From 2186f87343.

perldiag: Two minor tweaks

One typo and one copy-and-paste error.

perl.c: White space only

Properly indent a few lines

numeric.c: White-space only

Properly indent the branch of an 'if'.

regexec.c: Fix compiler warning

We add an #ifdef DEBUGGING around a variable declaration, as that
variable actually only gets used in DEBUGGING compiles.

make perl core quiet under -Wfloat-equal

The gcc option -Wfloat-equal warns when two floating-point numbers
are directly compared for equality or inequality, the idea being that
this is usually a logic error, and that you should be checking that the
values are instead very near to each other.

perl on the other hand has lots of reasons to do a direct comparison.

Add two macros, NV_eq_nowarn(a,b) and NV_eq_nowarn(a,b)
that do the same as (a == b) and (a != b), but without the warnings.
They achieve this by instead doing (a < b) || ( a > b).
Under gcc at least, this is optimised into the same code as the direct
comparison.

The are three places that I've left untouched, because they are handling
NaNs, and that gets a bit tricky. In particular (nv != nv) is a test for a
NaN, and replacing it with (< || >) creates signalling NaNs (whereas ==
and != create quiet NaNs)

porting/diag.t: restrict what's a warn function

add a couple of judicious \b's so that while warn() etc are seen
as calls to a warn-related function, this_is_not_a_warn() etc aren't.

This is needed for the next commit which will introduce the macro
NV_ne_nowarn().

perldiag: Remove ‘The %s feature...’

The idea when this was added was for ‘use feature’ to warn when
an experimental feature was enabled.  Things didn’t turn out that
way.  Only lexical subs follow that wording, and they have their
own entry in perldiag, so this one is unnecessary.

toke.c: Remove unnecessary assignment

LOP returns, so the value of orig_keyword is not used after this.

[Merge] Make &CORE:: subs respect vmsish hints

Most lexical hints are stored in the statement’s nextstate(ment)
op (aka cop or control op).  That op is available at run time as
PL_curcop, while the current op being executed is PL_op.

&CORE:: subs intentionally lack a nextstate op so they can see the
hints in the caller’s nextstate op.

Two vmsish hints were being stored in the current op, so &CORE::exit()
would not respect those hints, as &CORE::exit() executes the *same*
exit op each time.

This branch moves those hints to the nextstate op, so that &CORE::exit
behaves the same way as exit().

Make &CORE::exit respect vmsish exit hint

by removing the hint from the exit op itself and just having pp_exit
look in the cop hint hash, where it is already stored (as a result of
having been in %^H at compile time).

&CORE:: subs intentionally lack a nextstate op (cop) so they can see
the hints in the caller’s nextstate op.

Update dump.c for the exit->nextstate hush hint move

Update B::Concise for the exit->nextstate hush hint move

Fix &CORE::exit/die under vmsish "hushed"

This commit makes them behave like exit and die without the ampersand
by moving the OPpHUSH_VMSISH hint from exit/die op to the current
statement (nextstate/cop) instead.  &CORE:: subs intentionally lack a
nextstate op, so they can see the hints in the caller’s nextstate op.

Teach B::Concise about VMS hushed flag

Failing tests for &CORE::exit/die with vmsish

Fix pod screwup in a05ea1cf8be

Thanks to Daniel Dragan for pointing it out.

Long verbatim pod line in INSTALL

Consistent spaces after dots in sv.c apidocs

POD-only mention sv_setsv does get magic but not set magic

Warn for all uses of %hash{...} in scalar cx

and reword the warning slightly.

See <20131027204944.20489.qmail@lists-nntp.develooper.com>.

To avoid getting a warning about scalar context for ‘delete %a[1,2]’,
which dies anyway, I stopped scalar context from being applied to
delete’s argument.  Scalar context is not meaningful here anyway, and
the context is not really scalar.

This also means that ‘delete sort’ no longer produces a warning about
scalar context before dying, so I added a test for that.

Make _charnames comparison null-safe

This comparison in toke.c checks whether the charnames translators is
the core’s own and, if so, skips certain validation checks.

Charnames translators coming from any package beginning with
"_charnames\0" would also be exempt from the checks, because the name
comparison stopped at the first null.