| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
A large enough allocation request could wrap, causing MEXTEND to decide
the stack was already big enough.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An empty cpan/.dir-locals.el stops Emacs using the core defaults for
code imported from CPAN.
Committer's work:
To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed
to be incremented in many files, including throughout dist/PathTools.
perldelta entry for module updates.
Add two Emacs control files to MANIFEST; re-sort MANIFEST.
For: RT #124119.
|
| | |
|
| |
|
|
|
| |
and also implement the pp functions, though nothing compiles to
these ops yet.
|
| |
|
|
|
|
|
| |
pp.h: Remove stack-popping from void overload code
There is no need to pop the stack in void context, as every void-context
op is followed by something that resets the stack.
|
| |
|
|
|
| |
For functions only exported and not public, we can’t use the short
forms in pubic macros.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously in PUSH_EXTEND_MORTAL__SV_C, "PL_tmps_ix + 1" would execute
twice, once for the nonmutable if(>=), then again after the potential
tmps_grow call. tmps_grow has an unused return register/void proto, put it
to use by returning ix. Also change tmps_grow to take the result of
"PL_tmps_ix + the constant (usually 1) or non-constant (EXTEND_MORTAL)".
This avoid having to put the constant twice in machine code, once for the
if test, 2nd time for extend length param for tmps_grow call. For
non-constant/EXTEND_MORTAL usage, it allows the C optimizer to have the
length var to go out of liveness sooner if possible. Also the var used for
the if(>=) test is more likely to be in a register than length var.
So "if test variable" is closer on hand to the CPU than length var. In some
cases, if non-const len var isn't used again, it becomes the "ix" variable
by having PL_tmps_ix added to it. Change sv_2mortal to return sv instead
of NULL to remove a unique branch/block of machine code that assigns 0 to
return variable (Visual C didn't figure out return sv == returned NULL,
not sv). See also [perl #121845].
|
| |
|
|
|
|
|
| |
With commit 6f1401dc2a, most of the old overload macros stopped being
used. d4f7673c78 removed them. SETsv and SETsvUN were only used
by the removed macros, and are now completetly unused in core
and on CPAN.
|
| |
|
|
| |
OPpTARGET_MY is unrelated to MAXARG as far as I can tell.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new config file, regen/op_private, which contains all the
information about the flags and descriptions for the OP op_private field.
Previously, the flags themselves were defined in op.h, accompanied by
textual descriptions (sometimes inaccurate or incomplete).
For display purposes, there were short labels for each flag found in
Concise.pm, and another set of labels for Perl_do_op_dump() in dump.c.
These two sets of labels differed from each other in spelling (e.g.
REFC verses REFCOUNT), and differed in completeness and accuracy.
With this commit, all the data to generate the defines and the labels is
derived from a single source, and are generated automatically by 'make
regen'. It also contains complete data on which bits are used for what by
each op. So any attempt to add a new flag for a particular op where that
bit is already in use, will raise an error in make regen. This compares
to the previous practice of reading the descriptions in op.h and hoping
for the best.
It also makes use of data in regen/opcodes: for example, regen/op_private
specifies that all ops flagged as 'T' get the OPpTARGET_MY flag.
Since the set of labels used by Concise and Perl_do_op_dump() differed,
I've standardised on the Concise version. Thus this commit changes the
output produced by Concise only marginally, while Perl_do_op_dump() is
considerably different. As well as the change in labels (and missing
labels), Perl_do_op_dump() formerly had a bug whereby any unrecognised
bits would not be shown if there was at least one recognised bit.
So while Concise displayed (and still does) "LVINTRO,2", Perl_do_op_dump()
has changed:
- PRIVATE = (INTRO)
+ PRIVATE = (LVINTRO,0x2)
Concise has mainly changed in that a few op/bit combinations weren't being
shown symbolically, and now are. I've avoiding fixing the ones that would
break tests; they'll be fixed up in the next few commits.
A few new OPp* flags have been added:
OPpARG1_MASK
OPpARG2_MASK
OPpARG3_MASK
OPpARG4_MASK
OPpHINT_M_VMSISH_STATUS
OPpHINT_M_VMSISH_TIME
OPpHINT_STRICT_REFS
The last three are analogues for existing HINT_* flags. The former four
reflect that many ops some of the lower few bits of op_private to indicate
how many args the op expects. While (for now) this is still displayed as,
e.g. "LVINTRO,2", the definitions in regen/op_private now fully account
for which ops use which bits for the arg count.
There is a new module, B::Op_private, which allows this new data to be
accessed from Perl. For example,
use B::Op_private;
my $name = $B::Op_private::bits{aelem}{7}; # OPpLVAL_INTRO
my $value = $B::Op_private::defines{$name}; # 128
my $label = $B::Op_private::labels{$name}; # LVINTRO
There are several new constant PL_* tables. PL_op_private_valid[]
specifies for each op number, which bits are valid for that op. In a
couple of commits' time, op_free() will use this on debugging builds to
assert that no ops gained any private flags which we don't know about.
In fact it was by using such a temporary assert repeatedly against the
test suite, that I tracked down most of the inconsistencies and errors in
the current flag data.
The other PL_op_private_* tables contain a compact representation of all
the ops/bits/labels in a format suitable for Perl_do_op_dump() to decode
Op_private. Overall, the perl binary is about 500 bytes smaller on my
system.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PL_markstack_ptr was read once to do the ++ and comparison. Then after
the markstack_grow call, or not, depending on the branch. The code reads
PL_markstack_ptr a 2nd time. It has to be reread in case (or always does)
markstack_grow reallocs the mark stack. markstack_grow has a void retval.
That is a waste of a register. Let us put it to use to return the new
PL_markstack_ptr. In markstack_grow the contents that will be assigned to
PL_markstack_ptr are already in a register. So let the I32* flow out from
markstack_grow to its caller.
In VC2003 32 bit asm, mark_stack_entry is register eax. The retval of
markstack_grow is in eax. So the assignment "=" in
"mark_stack_entry = markstack_grow();" has no overhead. Since the other,
not extend branch, is function call free,
"(mark_stack_entry = ++PL_markstack_ptr)" assigns to eax. Ultimatly with
this patch a 3 byte mov instruction is saved for each instance of PUSHMARK,
and 1 interp var read is removed. I observed 42 callers of markstack_grow
with my disassembler, so theoretically 3*42 bytes of machine code was
removed for me.
Perl_pp_pushmark dropped from 0x2b to 0x28 bytes of x86 VC 2003
machine code. [perl #122034]
|
| |
|
|
| |
an expression and what's a statement.
|
| |
|
|
|
| |
As part of aad79b331c21c962b6e0ce7b8027aa625d7445ec, -DSTRESS_REALLOC was broken.
This should alleviate that.
|
| |
|
|
|
|
|
|
| |
Add PERL_UNUSED_VAR(sp) in case the EXTEND (or MEXTEND)
is the last thing mentioning the sp.
Addresses Coverity perl5 CIDs 29199..29201, 29204, 29205, 29206,
29208, 29210, 29212, 29213, 29215, 29216, 29219..29221.
|
| |
|
|
|
|
|
|
| |
I've gone through pp_hot.c and scope.c and added LIKELY() or UNLIKELY()
to all conditionals where I understand the code well enough to know that
a particular branch is or isn't likely to be taken very often.
I also processed some of the .h files which contain commonly used macros.
|
| |
|
|
|
|
| |
av_tindex is a more clearly named synonym for av_len, available starting
in v5.18. This changes the core uses to it, including modules in /ext,
which are not dual-lifed.
|
| | |
|
| |
|
|
| |
plus some typo fixes. I probably changed some things in perlintern, too.
|
| |
|
|
|
|
| |
This allows us easily to catch cases where the stack could move to a
new memory address while code still holds pointers to the old loca-
tion. Indeed, this causes test failures.
|
| |
|
|
|
|
| |
These shortcut macros are unused in the core, and unused by any code on CPAN.
If any XS code we can't see *is* using them, it will now fail to compile, and
can easily be fixed by replacing the macros with their expansion.
|
| |
|
|
|
|
|
|
|
|
| |
Make the array interface 64-bit safe by using SSize_t instead of I32
for array indices.
This is based on a patch by Chip Salzenberg.
This completes what the previous commit began when it changed
av_extend.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(I am referring to what is usually known simply as The Stack.)
This partially fixes #119161.
By casting the argument to int, we can end up truncating/wrapping
it on 64-bit systems, so EXTEND(SP, 2147483648) translates into
EXTEND(SP, -1), which does not extend the stack at all. Then writing
to the stack in code like ()=1..1000000000000 goes past the end of
allocated memory and crashes.
I can’t really write a test for this, since instead of crashing it
will use more memory than I have available (and then I’ll start for-
getting things).
|
| |
|
|
|
|
|
|
| |
This adds branch prediction hints to a few strategic places such as
growing stack or strings, some exception handling, and a few hot
functions such as sv_upgrade.
This is not exhaustive by any means.
|
| |
|
|
| |
This parameter is no longer used. Its value is always 0.
|
| |
|
|
|
| |
This macro is unused on CPAN and completely undocumented, so this
change should be safe.
|
| |
|
|
|
|
|
| |
This finishes the removal of register declarations started by
eb578fdb5569b91c28466a4d1939e381ff6ceaf4. It neglected the ones in
function parameter declarations, and didn't include things in dist, ext,
and lib, which this does include
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CVs close over their outer CVs. So, when you write:
my $x = 52;
sub foo {
sub bar {
sub baz {
$x
}
}
}
baz’s CvOUTSIDE pointer points to bar, bar’s CvOUTSIDE points to foo,
and foo’s to the main cv.
When the inner reference to $x is looked up, the CvOUTSIDE chain is
followed, and each sub’s pad is looked at to see if it has an $x.
(This happens at compile time.)
It can happen that bar is undefined and then redefined:
undef &bar;
eval 'sub bar { my $x = 34 }';
After this, baz will still refer to the main cv’s $x (52), but, if baz
had ‘eval '$x'’ instead of just $x, it would see the new bar’s $x.
(It’s not really a new bar, as its refaddr is the same, but it has a
new body.)
This particular case is harmless, and is obscure enough that we could
define it any way we want, and it could still be considered correct.
The real problem happens when CVs are cloned.
When a CV is cloned, its name pad already contains the offsets into
the parent pad where the values are to be found. If the outer CV
has been undefined and redefined, those pad offsets can be com-
pletely bogus.
Normally, a CV cannot be cloned except when its outer CV is running.
And the outer CV cannot have been undefined without also throwing
away the op that would have cloned the prototype.
But formats can be cloned when the outer CV is not running. So it
is possible for cloned formats to close over bogus entries in a new
parent pad.
In this example, \$x gives us an array ref. It shows ARRAY(0xbaff1ed)
instead of SCALAR(0xdeafbee):
sub foo {
my $x;
format =
@
($x,warn \$x)[0]
.
}
undef &foo;
eval 'sub foo { my @x; write }';
foo
__END__
And if the offset that the format’s pad closes over is beyond the end
of the parent’s new pad, we can even get a crash, as in this case:
eval
'sub foo {' .
'{my ($a,$b,$c,$d,$e,$f,$g,$h,$i,$j,$k,$l,$m,$n,$o,$p,$q,$r,$s,$t,$u)}'x999
. q|
my $x;
format =
@
($x,warn \$x)[0]
.
}
|;
undef &foo;
eval 'sub foo { my @x; my $x = 34; write }';
foo();
__END__
So now, instead of using CvROOT to identify clones of
CvOUTSIDE(format), we use the padlist ID instead. Padlists don’t
actually have an ID, so we give them one. Any time a sub is cloned,
the new padlist gets the same ID as the old. The format needs to
remember what its outer sub’s padlist ID was, so we put that in the
padlist struct, too.
|
| |
|
|
|
|
| |
In the absence of n_a (see 8c074e2a and 95fad918), there is no differ-
ence between [TP]OPp and [TP]OPpx except speed, so there is no reason
for the x-less variant to be deprecated.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was brought up in ticket #113812.
Formats that are nested inside closures only work if invoked from
directly inside that closure. Calling the format from an inner sub
call won’t work.
Commit af41786fe57 stopped it from crashing, making it work as well
as 5.8, in that closed-over variables would be undefined, being
unavailable.
This commit adds a variation of the find_runcv function that can check
whether CvROOT matches an argument passed in. So we look not for the
current sub, but for the topmost sub on the call stack that is a clone
of the closure prototype that the format’s CvOUTSIDE field points to.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
amagic_call now does its best to propagate the operator's context into
the overload callback. It's not always possible - for instance,
dereferencing and stringify/boolify/numify always have to return a
value, even if it's not used, due to the way the overload callback works
in those cases - but the majority of cases should now work. In
particular, overloading <> to handle list context properly is now
possible.
For backcompat reasons (amagic_call and friends are technically public
api functions), list context will not be propagated unless specifically
requested via the AMGf_want_list flag. If this is passed, and the
operator is called in list context, amagic_call returns an AV* holding
all of the returned values instead of an SV*. Void context always
results in amagic_call returning &PL_sv_undef.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit bee7c5743fa appears to have fixed this. But what it does is
barely significant:
diff --git a/sv.c b/sv.c
index b96f7c1..a4994f5 100644
--- a/sv.c
+++ b/sv.c
@@ -9525,6 +9525,11 @@ Perl_sv_bless(pTHX_ SV *const sv, HV *const stash)
SvUPGRADE(tmpRef, SVt_PVMG);
SvSTASH_set(tmpRef, MUTABLE_HV(SvREFCNT_inc_simple(stash)));
+ if (Gv_AMG(stash))
+ SvAMAGIC_on(sv);
+ else
+ (void)SvAMAGIC_off(sv);
+
if(SvSMAGICAL(tmpRef))
if(mg_find(tmpRef, PERL_MAGIC_ext) || mg_find(tmpRef, PERL_MAGIC_uvar))
mg_set(tmpRef);
The crash can still be triggered another way. Instead of a blessing,
we need to modify a method (to turn on the potentially-overloaded
flag) and then use an operator that respects overloading. This exam-
ple crashes before and after bee7c5743fa:
eval 'sub Sample::foo {}';
"".bless {},'Sample';
delete local $Sample::{ '()' };
It is the recalculation of overload caches before a localised deletion
that causes the crash. And it only happens when the '()' key does
not exist.
Actually, it turns out that S_delete_local doesn’t behave correctly
for rmagical aggregates, except for %ENV:
$ ./perl -Ilib -MDevel::Peek -e 'delete local $ISA[0]'
Bus error
$ ./perl -XIlib -MDevel::Peek -e '??; delete local $::{foo}'
Bus error
It’s this line, which occurs twice in pp.c:S_do_delete_local, which
is at fault:
const bool can_preserve = SvCANEXISTDELETE(osv)
|| mg_find((const SV *)osv, PERL_MAGIC_env);
When can_preserve is true, the ‘preeminent’ variable is set based on
whether the element exists. Otherwise it is set to true.
Why the term ‘preeminent’ was chosen I don’t know, but in this case it
means that the element already exists, so it has to be restored after-
wards. We can’t just do save_delete.
The code for saving a hash element assumes it is non-null, and crashes
otherwise.
The logic for setting can_preserve is wrong. SvCANEXISTDELETE returns
true for non-magical variables and for variables with those tie meth-
ods implemented. For magical variables that are not tied, it returns
the wrong answer. PERL_MAGIC_env seems to have been added as an
exception, to keep it working. But other magical aggregates were not
accounted for.
This logic was copied from other functions (aslice, hslice, etc.),
which are similarly buggy, but they don’t crash:
$ ./perl -Ilib -le ' { local $::{foo} } print exists $::{foo}'
$ ./perl -Ilib -le 'm??; { local $::{foo} } print exists $::{foo}'
1
In all these cases, it is SvCANEXISTDELETE that is buggy. So this
commit fixes it and adds tests for all the code paths that use it.
Now no exception needs to be made for PERL_MAGIC_env.
|
| |
|
|
|
| |
This updates the editor hints in our files for Emacs and vim to request
that tabs be inserted as spaces.
|
| |
|
|
| |
I mistakenly thought XPUSHs(...) was an expression. Now it is.
|
| |
|
|
| |
This wasn’t affecting anything, but was a bug waiting to happen.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only uses of USE_LEFT in core now occur when SvGETMAGIC has
already been called. So returning true for magical SVs is not neces-
sary. In fact, it was never correct.
Also, the code in do_vop (which handles bitwise operations on strings)
to avoid an uninitialized warning had the same buggy SvGMAGICAL check.
Now, the warning from $uninit += 1 is suppressed for all undefined
vars, not just amagical ones.
This causes 6 to-do tests in assignwarn.t to pass.
|
| |
|
|
|
|
| |
These are undocumented and unused on CPAN and in the core.
The core now uses _nomg variants.
|
| |
|
|
|
|
| |
This patch uses the recently-added MAYBE_DEREF_GV macro which puts the
glob deref logic in one spot. It also adds _nomg and _flags varia-
tions of it. _flags understands the SV_GMAGIC flag.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Commit 557fbd17eb added the MAYBE_DEREF_GV macro, which 2ea1cce
applied to chdir, chmod and chown.
That macro calls get-magic on its arguments checks to see if it might
be a gv or ref and, if it’s a ref, calls get-magic on the referent,
to see whether it will turn into a gv. That means we’ll end up with
chdir($array_obj) calling get-magic on the array. While probably
harmless, calling get-magic is superfluous and probably incorrect. I
don’t know that there is a reasonable way to test this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are so many parts of the core (mostly pp functions or functions
they call) that need a glob or a globref, including many that call
get-magic at the wrong time (or not at all in some cases, that it
makes sense to add a macro to do it.
It can be used like this:
if (gv = MAYBE_DEREF_GV(sv)) /* calls get-magic */
{
}
else { /* avoid magic here */
}
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This restores the old definition of dPOPTOPiirl_nomg from
before 96b6b87 and the old definition of dPOPXiirl_ul_nomg from
before e62ca0f (except for a bug fix: POPi cannot be used since
it’s magical). It also reverts most of c31c291.
This does mean that uninitialized warnings for various operators are
back in reverse order. So I am reinstating a bug with this commit. But
that bug was never a 5.14 blocker and so should never have been fixed
during code freeze (and there is the slight possibility that the fix
would break sensitive test suites). It was only fixed ‘for free’ as a
side effect of fixing [perl #87708], but that bug turned out to have a
better fix (commit 75ea7a1) that allows these changes to be reverted.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The short story: In 5.13.1 or .2 these ops started calling get-magic
just once if the same gmagical scalar was used for both operands. Then
the same value would be used on both sides. In 5.12 FETCH would be
called twice with both return values used, but they would be swapped
in most cases (so $t/$t would return 1.5 if $t returned 2 and then
3). Now FETCH is called twice and the two operands are used in the
right order.
Up till now there have been patches to fix specific ops, but I real-
ised that the same ten or so lines of code would have to be added to
the rest of the 20+ pp_ functions, all of which use tryAMAGICbin_MG
(which calls Perl_try_amagic_bin in gv.c), so it made sense to add the
code to Perl_try_amagic_bin instead. This fixes all the ops in one
fell swoop.
The code in question checks whether the left and right operands are
the same gmagical scalar. If so, it copies the scalar into a new mor-
tal one, and then calls get-magic on the original operand to get its
new value (for the rhs). The new scalar is placed just below the top
of the stack, so it becomes the left operand.
This does slow down the bitwise integer ops slightly, but only in this
rare edge case. And the simplification of the code seems worth it.
Forthcoming are commits that revert some of the changes already made,
as this commit renders them unnecessary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is just part of #87708.
This fixes the % and * operators under ‘use integer’ when the same
tied scalar is used for both operands and returns two different val-
ues. Before this commit, get-magic would be called only once and
the same value used. In 5.12.x * just worked but the operands were
swapped for %.
It turns out that every operator using the dPOPTOPiirl_nomg macro
needs exactly the same treatment, so this commit eliminates the
dPOPTOPiirl_halfmg macro added a few commits ago and modifies
dPOPTOPiirl_nomg to do was it was doing. This should be perfectly
safe, as dPOPTOPiirl_nomg has not been in a stable release (and is
only for internal use anyway).
|
| |
|
|
|
|
|
|
|
| |
This is just part of #87708.
This fixes + and - under ‘use integer’ when the same tied scalar is
used for both operands and returns two different values. Before this
commit, get-magic would be called only once and the same value used.
In 5.12.x + just worked but the operands were swapped for -.
|
| |
|
|
|
|
|
|
|
| |
This is just part of #87708.
This fixes <=> under ‘use integer’ when the same tied scalar is used
for both operands and returns two different values. Before this com-
mit, get-magic would be called only once and the same value used. In
5.12.x, the operands would be reversed.
|
| |
|
|
|
|
|
| |
This fixes atan2 when the same tied scalar is used for both operands
and returns two different values. Before this commit, get-magic would
be called only once and the same value used. In 5.12.x, the operands
would be reversed.
|
| |
|
|
|
| |
Add a flag TIED_METHOD_SAY to Perl_tied_method(), to allow tied PRINT to
effect C<local $\ = "\n";> within the ENTER/LEAVE pair of Perl_tied_method().
|
| |
|
|
| |
It can be used for (at least) the call to "SPLICE" from pp_splice.
|
| | |
|
