perlsec: Another typo

perlsec: Typo

perlsec: Consistent spaces after dots

perldelta for 59e6df9f1cf

perldelta for 172a6a76e8c

Add perldelta entry for ExtUtils::Manifest upgrade.

=for apidoc wrong api

Couple more infnan tests.

sqrt() disappeared in OSX, assuming it became pow().

Use exp() instead, less likely to disappear.  Yes, handwaving.

AIX: if long doubles do not mix with infinity, disable long doubles.

Detect HAS_AIX_POWL_NEG_BASE_BUG in hints/aix.sh

The fp classification is a royal mess.

Try avoiding false detections by guarding against an interface falsely
matching a set of return values.  This can still go wrong if <math.h>
declares several sets.  Would really need an array of Configure tests.

Wrong result for double-double sqrt(2).

S_infnan_copy needs at most 5 bytes of output size.

Do not test sin/cos at [+-]pi, either.

With AIX and long doubles you may not get exactly the approximation
of pi you were thinking of.  "This is not the pi you are looking for".

Avoid using function pointers for math functions.

Otherwise AIX with long double has issues, see perl #122571.  AIX has
some rather intricate arrangement of symbols and macros.  Also, it is
okay to use two switches instead of just one.

Update ExtUtils-Manifest to CPAN version 1.66

  [DELTA]

1.66  Sun, Aug 31, 2014
  - manifind() will now follow symlinks
  - Tests fixed if PERL_MM_MANIFEST_VERBOSE env var is set to
    false value
  - Fixed bug with maniread()'s handling of quoted filenames

perldelta for 8b57a5fa

perldelta for 211a4342

perldelta for f20d0df0f

perldelta for 4dda930be/#122556

perldelta: A to-do item

Mostly my own reminder, because I have not rebased yet, and this
entry will conflict with something already pushed.

perldelta for 8380b6901

perldelta for acb187b49 (part of #69456)

perldelta for eff754733a9

perldelta for #80368/e4916dd1b3

Stop prototype declaration from clobbering constants

$ perl -e 'use constant f=>3; sub f($); warn eval "&f"'
Runaway prototype at -e line 1.
Prototype mismatch:: none vs ($) at -e line 1.
Undefined subroutine &main::f called at (eval 1) line 1.
...caught at -e line 1.
$ perl -e 'sub f (){3} sub f($); warn eval "&f"'
Prototype mismatch: sub main::f () vs ($) at -e line 1.
3 at -e line 1.

(The ‘Runaway prototype’ warning was removed in acfcf464b177, in which
I stated wrongly that the warning could only come about with stash
manipulation.  I suppose the warning was really warning me that the
implementation was broken, which it was until this commit.)

When constant refs in the symbol table were introduced in 5.10.0
(a bisect points to e040ff70dc), one code path in newATTRSUB--that
assumes that a stash entry that is not a GV is not a defined sub,
but either a forward declaration or no sub at all--was not updated to
account for this new way of storing constants.

Stop anon sub compilation from clobbering __ANON__

Anonymous subs point to *__ANON__ simply because internals expect
defined subroutines to have CvGV pointing somewhere.

So why does anonymous constant sub compilation wipe
*__ANON__{CODE} clean?

$ perl -e 'sub main::__ANON__ { 42 }; warn main::__ANON__; # sub(){3}'
42 at -e line 1.
$ perl -e 'sub main::__ANON__ { 42 }; warn main::__ANON__;  sub(){3}'
Undefined subroutine &main::__ANON__ called at -e line 1.

It doesn’t happen with non-constant subs:

$ perl -e 'sub main::__ANON__ { 42 }; warn main::__ANON__;  sub{3}'
42 at -e line 1.

This is actually a regression:

../perl.git/Porting/bisect.pl  --end=perl-5.8.8  --target=miniperl -e  'sub main::__ANON__ { 42 }; warn main::__ANON__;  sub(){3}'

beab0874143b7208922720fecefc4a224011fa25 is the first bad commit
commit beab0874143b7208922720fecefc4a224011fa25
Author: John Tobey <jtobey at john-edwin-tobey.org>
Date:   Fri Oct 20 18:03:27 2000 -0400

    Re: Creating const subs for constants.
    Message-Id: <m13mo0N-000FObC@feynman.localnet>

    p4raw-id: //depot/perl@7389

The new code path for constants did an unconditional
GvCV_set(gv, NULL), instead of checking whether there was a
name first.

Porting/bisect.pl: Add missing full stop

add missing close paren in pod

For: RT #122663 (partial)

sig() should be kill()

There is no sig() function, and the block of text has similar language
to a previous block which uses kill().

For: RT #122662

Add perldelta entries for updated modules and pragmata.

Another way to detect C99.

HAS_C99 was oddly defined, and oddly used.

It was defined as "C version high enough, but not VMS",
but used as "does it have intmax_t".  Now that we have
I_STDINT, we can do better.

Configure: add i_stdint.

apidoc for Perl_isinfnan.

Add a simple atan2() test.

(Not similar to the 'torture tests' that were removed.)

Check validity of keys in hash passed as first argument.

Prevent processing of misspelled options in hash passed to find() or
finddepth().

Add perldelta entry for File::Find.

For: RT #122547

Fix up Peek.t after priv flag twiddling

Stop turning off bit 1 in rv2cv private flags

newUNOP turns on that bit by default, to indicate that the op
has one kid.

rv2cv was using that bit for something else, so three code paths had
to turn it off.

Two commits ago, rv2cv stopped using that bit, so turning it off
is no longer necessary.  It was because the flag using that bit,
OPpMAY_RETURN_CONSTANT, needed to be passed to newUNOP, that it had
to change.

Increase $B::Concise::VERSION to 0.993

Update B::Concise for OPpMAY_RETURN_CONSTANT

Avoid vivifying stuff when looking up barewords

Till now, when a bareword was looked up to see whether it was a sub-
routine, an rv2cv op was created (to allow PL_check hooks to override
the process), which was then asked for its GV.

Afterwards, the GV was downgraded back to nothing if possible.

So a lot of the time a GV was autovivified and then discarded.  This
has been the case since f74617600 (5.12).

If we know there is a good chance that the rv2cv op is about to be
deleted, we can avoid that by passing a flag to the new op.

Also f74617600 actually changed the behaviour by vivifying stashes
that used not be vivified:

sub foo { print shift, "\n" }
SUPER::foo bar if 0;
foo SUPER;

Output in 5.10:

    SUPER

Output as of this commit:

    SUPER

Output in 5.12 to 5.21.3:

    Can't locate object method "foo" via package "SUPER" at - line 3.

[Merge] pad_reset

This branch gets builds with pad_reset enabled working and changes the

For those who do not know what pad_reset does, pad_reset allows oper-
ators from different statements to share targets, saving memory.  When
it was originally added, it never fully worked properly, so it was
disabled, since it caused bugs.

For those who do not know what operator targets are:  Many operators
use the same scalar every time they return a value, to avoid having to
create a new one each time.  This is known as the target.

To keep t/re/uniprops.t running in a reasonable amount of time (unfor-
tunate coincidences slowed it down signficantly), I had to add two
optimisations.  See the commits entitled:

    Split PL_padix into two variables
    pad.c: Use PadnamelistMAXNAMED in another place

These optimisations apply even when pad_reset is disabled.

Benchmarking doesn’t show any speedup with pad_reset
enabled, so I left it disabled for now.  See
<20140828045810.19174.qmail@lists-nntp.develooper.com> for benchmark-
ing details.

(I am hoping that I can figure out why it’s slower and enable it some
future date.)

Make Peek.t easier to run directly

e.g., ./perl -TIlib ext/Devel-Peek/t/Peek.t

pad.c: pad_reset comments

Fix up Peek.t

pad.c: Remove BROKEN from USE_BROKEN_PAD_RESET

pad.c:pad_free: Don’t reset PL_padix if using pad_reset

pad_reset causes PL_padix to be reset at the beginning of each state-
ment, so that operator targets can be reused.

If we also reset it when freeing an operator, then theoretically tar-
gets from operators later on in the same statement might be reused.  I
can’t come up with a test case, but it’s better to be safe than sorry.

pad.c:pad_findmy_pvn: Skip ‘our’ hack for subs

There is a hack that allows an ‘our’ variable to be found in the pad
in the statement in which it is declared, to avoid a warning (since
the fallback would be to look up the very same variable in the current
package anyway).

Since the warning this hack avoids doesn’t apply to subroutines, we
can just skip it for subroutine lookup.

pad.c: Use PadnamelistMAXNAMED in another place

This will speed up pad lookup a little more.  This could be considered
a follow-up to commit 7db6405c.

There is a hack that allows an ‘our’ variable to be found in the pad
in the statement in which it is declared, to avoid a warning (since
the fallback would be to look up the very same variable in the current
package anyway).

This commit applies the PadnamelistMAXNAMED optimisation to that code
path.  This is how that optimisation works:  When named slots are
allocated in the pad, PadnamelistMAXNAMED is set, so that, when
searching for named items in the pad, we don’t have to search the
whole thing if there are many constants or GVs at the end.

Recent commits slowed down t/re/uniprops.t considerably.  This was the remaining bottleneck.

We could actually skip the whole ‘our’ hack for subroutine lookup
(since the warning it avoids doesn’t apply to subroutines anyway).  In
fact, the next commit will do that.  But this optimisation is worth-
while anyway.

Split PL_padix into two variables

PL_padix keeps track of the position in the pad when pad_alloc has to
start scanning for an available slot.

The availability of a slot is determined differently for targets
(which may reuse slots that are already targets from previous state-
ments, at least when pad_reset is enabled) and constants (which may
not reuse targets).

Having the same index for both may require scanning the entire pad for
allocating a constant or GV.

t/re/uniprops.t was running far too slowly under USE_BROKEN_PAD_RESET
because of this.  pad_reset would reset PL_padix to point to the
beginning of a pad with a few hundred thousand entries.  pad_alloc
would then have to scan the entire pad before adding a GV to the end.

It is still too slow, even with this commit, but for other reasons.
(This is just a partial fix.)

intrpvar.h: Correct comment

This description has been a little faulty for quite some time, not
just because of the last few commits.  Any time pad_free or pad_swipe
is called, that pad slot becomes available and PL_padix is reset.
So ‘max used’ is not accurate.

uniprops.t: Correct command line in comment

op.c:newPADOP: Allocate GV pad slots like constants

Requesting a pad slot for a constant (and GVs in pads are like con-
stants, in that the pad slot will always hold that same value, which
is shared in recursion) will instruct pad_alloc to avoid anything
marked PADTMP; i.e., a  slot used as a target by a previous statement.

Without this, under -Accflags=-DUSE_BROKEN_PAD_RESET and threads,
configpm fails an assertion, because a concat operator tries to do
sv_grow on its target, but that target has ended up becoming a GV.

With this commit, all tests pass, but t/re/uniprops.t takes ‘forever’
(cf. commits 325e1816 and 7db6405c, which caused and fixed, respec-
tively, a similar bug).

pad.c:pad_free: Don’t turn off the PADTMP flag

When we mark a pad entry as being free, it may happen (under
USE_BROKEN_PAD_RESET) that multiple operators from different state-
ments are using the same pad entry for their targets.  If we turn off
the PADTMP flag, the slot may be reused for a constant.  Then an oper-
ator that tries to return a value by assigning to its target will try
to modify a read-only scalar.

Now that (as of a few commits ago) allocation of targets (in
pad_alloc) will reuse entries marked PADTMP, turning off the flag is
not necessary to make a slot available.

This gets the build for USE_BROKEN_PAD_RESET+threads a little further.
The Exporter test now passes, but configpm trips an assertion....

op.c:ck_rvconst: Allocate GV pad slots like constants

Requesting a pad slot for a constant (and GVs in pads are like con-
stants, in that the pad slot will always hold that same value, which
is shared in recursion) will instruct pad_alloc to avoid anything
marked PADTMP; i.e., a  slot used as a target by a previous statement.

Without this, we get an assertion failure from ‘miniperl -MExporter’
under -Accflags=-DUSE_BROKEN_PAD_RESET and threads.

With this commit, we get ‘Modification of a read-only value attempted’
instead, which is some progress. :-)

pad.c: More clearly separate targ/constant allocation

pad_reset was turning off PADTMP on targets to make them ‘available’
again.  But constants allocated later could then end up using those
slots.  We can’t share pad slots between constants and targets,
because operators allocated earlier will trigger ‘Modification of
a read-only value’ errors when trying to assign return values to
their targets.

Under non-threaded builds, in which constants are not generally stored
in the pad, there are still ‘constants’ that are allocated as such
(with &PL_sv_no names) but are not actually read-only.  Filehandle
names associated with ‘open my $fh’ are one such example.  If that
filehandle name’s pad slot is shared with a target, then the file-
handle will be named using some random string from a previous
statement.

The solution here is to change the way we use the PADTMP flag when
allocating pad slots.  pad_reset should *not* turn off the flag,
because we need to know that these entries are used as targets by pre-
vious statements.  pad_alloc should not tread PADTMP entries as being
in use when allocating targets, but only when allocating constants.

This gets all tests passing under -Accflags=-DUSE_BROKEN_PAD_RESET
on non-threaded builds.

pad.c:pad_reset: Also make sure the thing is not PADMY

We can’t SvPADTMP_off on just anything, because it asserts that the
thing is !SvPADMY.

A range operator has a target of sorts, but that target must not be
shared with any other operators; hence it gets allocated like a
‘my’ variable.  The target thus ends up with the SvPADMY flag set.  We
obviously don’t want to mark those targets as reusable in pad_reset,
so just skip them.

This gets things mostly working under USE_BROKEN_PAD_RESET without
threads, but a few tests still fail.

pad.c:pad_reset: check the name

This code was sufficiently out-of-date to trip assertions in miniperl,
breaking the build (with -Accflags=-DUSE_BROKEN_PAD_RESET).

We can’t SvPADTMP_off on just anything, because it asserts that the
thing is !SvPADMY.

So check that it has no name first.  A pad entry without a name is an
operator target (or an unallocated entry).

The build is still broken, but it gets a bit further.

Alphabetise perldiag

Earlier in perldiag, it says:

    The messages are in alphabetical order, without regard to upper or
    lower-case.

perldiag grammar

1cd88304d70 fixed one grammatical error in this sentence.  This fixes
the other.

t/porting/readme.t: Get list from MANIFEST

Otherwise we end up failing because of editor or patch droppings
in Porting/.  The test was already skipping things ending with ~
but that was not sufficient.

[Merge] Fix crashes with lexical subs

Various crashing resulting from code not taking CvGV(lexsub)==NULL
into account.

Fix crash with lex subs under -d

Fix crash in leave_scope when my sub has CvGV

Sub declaration can reuse an existing stub.  So it is possible to define
a package sub using a stub that was originally lexical.  Hence,
leave_scope needs to take into account that a my-sub may not have a
name hek any more.

Fix crash when lex subs are used for overload

Fix crash when lex subs are used for AUTOLOAD

[perl #122556] Make undef $s free refs forthwith

Don't use isfinitel/isinfl/isnanl if the C99 macros exist.

Moves the C99 logic from sv.c (?) to perl.h.

Under C99 isfinite/isinf/isnan are sizeof-aware macros.

So let's not test them with inlibc.

regcomp.c: Silence Win32 compiler warning

This raised a signed/unsigned warning that is essentially spurious.

sv_grow: performance improvement for short strings

Empty COW strings with CUR=0 ended up allocated as LEN=10.
Now they are rounded up to 4 or 8.

Timings:
+0   16.394324103 0.27%
+2   16.114379842 0.01%
+4   16.305622265 1.03%
+8   16.337438609 1.30%
+10  16.675009468 0.59%
with LD_LIBRARY_PATH=`pwd` perf stat -r2 ./perl t/harness t/op/*.t

+2 was consistently the best number, and +10 the worst.

Upgrade to threads 1.96

todo: expand the list of OS access builtins to update

...taken from an IRC conversation on #p5p

De-prefix Perl_isinfnan.

pack c/C on inf/nan.

Made them return the 0xFF byte (and warn).  Not necessarily the best
choice, but there's not that much room in just 256 bytes for all of
the inf/-inf/nan.  This same choice will need to be made with wider
integer packs.

Make sprintf %c and chr() on inf/nan return the U+FFFD.

%c was made to produce "Inf"/"NaN" earlier, but let's
keep with the Unicode way, and make chr() agree with %c.

NVgf/NVff agree with -Duselongdouble.

Comment tweak.

ext/re/t/regop.t: Use eq instead of == for strings

Interestingly, this bug has been unnoticed for almost 3 years.

Detect false infinities.

printf inf/nan should be inf/nan.

Before: printf %[ducp] for Inf/NaN produced quite surprising results:
1, 0, -1, 18446744073709551615, 9223372036854775808, -9223372036854775807,
bogus Unicode code points, random heap addresses in hex.

Add more infnan tests.

Avoid useless warning, remove debug code.

*fp*class* comment tweaks.

Post-VAX VMS has fp_classify().

Simplify the hexfp space computation.

And prepare for the double double case being properly implemented.

Comment why hexfp is set here, not earlier.

Only one successful exit from grok_infnan().

Sprinkle the fact that long doubles aren't standardized.

Allow eg ./perl t/harness t/op/lc.t

Typo in pad.c apidocs

Porting/Maintainers.pl - Fix ExtUtils-CBuilder entry

Upgrade version from version 0.9908 to 0.9909

This includes some blead changes, but more are still waiting to be
incorporated into the next CPAN release, namely 7738054cc9 and dcccc8ffbf.

constant.pm: Document fully-qualified constant names

added a few commits ago.

constant.pm: Remove doc reference to compile-time checking

This was removed in commit eff754733a.  It was necessary, as the
feature caused bugs #69456 and #122607.

Advertising the compile-time check with version-dependent qualifi-
cations would make the documentation too verbose.

constant.pm: Remove redundant truth checks

It is not possible to reach these without $symtab’s having been
assigned a stash reference.

constant.pm: outdated comment

Increase $constant::VERSION to 1.32