| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Mostly in comments and docs, but some in diagnostic messages and one
case of 'or die die'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is being done only for those functions that don't have a guard
preventing them from being seen outside of the Perl core.
Talking to Tony Cook, we agreed that this was a good idea for two
reasons:
1) The 'Perl_' prefix does not pollute XS caller's name space. The 'S_'
one could be argued that it doesn't much either, but it does more so
than 'Perl_', and the next reason is the clincher:
2) It allows us to change our minds about whether a function should be
static inline or not, without affecting callers who use the Perl_
form, which they would be accustomed to anyway if they're using the
full name form.
|
| |
|
|
|
|
|
|
|
|
| |
This makes various fixes to the text that is used to generate the
documentation. The dominant change is to add the 'n' flag to indicate
that the macro takes no arguments. A couple should have been marked
with a D (for deprecated) flag, and a couple were missing parameters,
and a couple were missing return values.
These were spotted by using Devel::PPPort on them.
|
| |
|
|
|
|
| |
This indicates to not output the macro with parentheses for parameters.
Currently that doesn't happen anyway, but a future commit will change
things so this is required (so that a bug can be fixed)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I added this flag a few years ago when I revamped the overload macros
tryAMAGICbin() etc. It allowed two different classes of macros to
share the same functions (Perl_try_amagic_un/Perl_try_amagic_bin)
by indicating what type of action is required.
However, the last few commits have made those two functions able to
robustly always determine whether its an assign-type action
($x op= $y or $lex = $x op $x) or a plain set-result-on-stack operation
($x op $y).
So eliminate this flag.
Note that this makes the ops which have the AMGf_set flag hard-coded
infinitesimally slower, since Perl_try_amagic_bin no longer skips the
checks for assign-ness. But compared with the overhead of having
already called the overload method, this is is trivial.
On the plus side, it makes the code smaller and easier to understand.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This macro is defined as
(PL_op->op_flags & OPf_STACKED)
and indicates, for ops which support it, that the mutator-variant of the
op is present (e.g. $x += 1).
This macro was mainly used as an arg for the old-style overloading
macros (tryAMAGICbin()) which were eliminated several years ago.
This commit removes its vestigial usage, and instead tests OPf_STACKED
directly at each location, along with adding a comment about the
significance of the flag.
This removes one item of obfuscation from the overloading code.
There is one potentially functional change in this commit:
Perl_try_amagic_bin() was sometimes testing for OPf_STACKED without
first checking that it had been called with the AMGf_assign flag (which
indicates that this op supports a mutator variant). With this commit, it
now checks first, so this is theoretically a bug fix. In practice that
section of code was never reached without AMGf_assign always being set
anyway.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On debugging builds only, add a mechanism for checking pp function calls
for insufficient stack extending. It works by:
* make the runops loop set a high-water-mark (HWM) variable equal to
PL_stack_sp just before calling each pp function;
* make EXTEND() etc update this HWM;
* on return from the pp function, panic if PL_stack_sp is > HWM.
This detects whether pp functions are pushing more items onto the stack
than they are requesting space for.
There's a possibility of false positives if the code is doing weird stuff
like direct manipulation of stacks via PL_curstack, SWITCHSTACK() etc.
It's also possible that one pp function "knows" that a previous pp
function will have already grown the stack enough. Currently the only
place in core that seems to do this is pp_enteriter, which allocates 1
stack slot so that pp_iter doesn't have to check each time it returns
&PL_sv_yes/no. To accommodate this, the new macro EXTEND_SKIP() has been
added, that tells perl that it's safely skipping an EXTEND() here.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++11 requires space between the end of a string literal and a macro, so
that a feature can unambiguously be added to the language. Starting in
g++ 6.2, the compiler emits a warning when there isn't a space
(presumably so that future versions can support C++11). Unfortunately
there are many such instances in the perl core. This commit fixes
those, including those in ext/, but individual commits will be used for
the other modules, those in dist/ and cpan/.
This commit also inserts space at the end of a macro before a string
literal, even though that is not deprecated, and removes useless ""
literals following a macro (instead of inserting a blank). The result
is easier to read, making the macro stand out, and be clearer as to the
intention.
Code and modules included with the Perl core need to be compilable using
C++. This is so that perl can be embedded in C++ programs. (Actually,
only the hdr files need to be so compilable, but it would be hard to
test that just the hdrs are compilable.) So we need to accommodate
changes to the C++ language.
|
| |
|
|
|
|
| |
Use static inline functions to avoid having different code paths
for GCC and non-GCC. INCMARK is unused on CPAN and only used as
a statement in core, so it can become a statement.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The value of gimme stored in the context stack is U8.
Make all other uses in the main core consistent with this.
My primary motivation on this was that the new function cx_pushblock(),
which I gave a 'U8 gimme' parameter, was generating warnings where callers
were passing I32 gimme vars to it. Rather than play whack-a-mole, it
seemed simpler to just uniformly use U8 everywhere.
Porting/bench.pl shows a consistent reduction of about 2 instructions on
the loop and sub benchmarks, so this change isn't harming performance.
|
| |
|
|
| |
whitespace-only changes
|
| |
|
|
|
|
|
| |
The debugging variants of POPMARK() etc: use %IVdf rather than %d
to avoid compiler warnings when sizeof(IV) != sizeof(int);
also, make these macros trigger only under -Dsv rather than just -Ds
(-v is the verbose variant).
|
| |
|
|
|
|
|
| |
Most integers are small, so in most cases it won't be set.
The other option would be to always clear it, but that increases the
amount of inline code for a rare case.
|
| |
|
|
|
|
|
|
|
|
| |
v5.23.3-305-g6cae08a introduced debugging variants of INCMARK/POPMARK, and
replaced a number of "PL_markstack_ptr--;" with "POPMARK;" etc.
This spews a bunch of "value computed is not used" warnings; so
add some "(void)"s.
Also indent the new definitions of INCMARK/POPMARK correctly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These macros are used by many pp functions to set TARG to an int or float
value and put it on the stack. The macros use a call to sv_setiv()
or similar.
However, there is a good chance that the target is ether a lexical var
or a PADTMP that has been assigned just an IV/NV in the past, in which
case its body is likely to still be of type SVt_IV/SVt_NV. If this is
the case, we can set its value much more efficiently.
Update those setting macros to first check if the target has a simple
body, and if so, set directly.
This makes quite a significant performance difference on code that does
a lot of arithmetic, at the cost of a larger binary (0.36% on my Linux
x86_64 system).
It also allows you (at compile time) to skip testing for taint if you
know that the value can't be tainted (e.g. pp_add() when both args are
non-magical and so can't have taint magic attached). The next commit will
make use of this.
Includes a couple of efficiency tweaks suggested by Daniel Dragan.
|
| |
|
|
|
| |
display the MARK arity and pointers with MARK macros.
assert on markptr underflow.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes various issues around stack_grow() and its
two main wrappers, EXTEND() and MEXTEND(). In particular it behaves
very badly on systems with 32-bit pointers but 64-bit ints.
One noticeable effect of this is commit is that various usages of EXTEND()
etc will now start to give compiler warnings - usually because they're
passing an unsigned N arg when it should be signed. This may indicate
a logic error in the caller's code which needs fixing. This commit causes
several such warnings to appear in core code, which will be fixed in the
next commit.
Essentially there are several potential false negatives in this basic
code:
if (PL_stack_max - p < (SSize_t)(n))
stack_grow(sp,p,(SSize_t)(n));
where it incorrectly skips the call to stack_grow() and then the caller
tramples over the end of the stack because it assumes that it has in fact
been extended. The value of N passed to stack_grow() can also potentially
get truncated or wrapped.
Note that the N arg of stack_grow() is SSize_t and EXTEND()'s N arg is
documented as SSize_t. In earlier times, they were both ints.
Significantly, this means that they are both signed, and always have been.
In detail, the problems and their solutions are:
1) N is a signed value: if negative, it could be an indication of a
caller's invalid logic or wrapping in the caller's code. This should
trigger a panic. Make it so by adding an extra test to EXTEND() to
always call stack_grow if negative, then add a check and panic in
stack_grow() (and other places too). This extra test will be constant
folded when EXTEND() is called with a literal N.
2) If the caller passes an unsigned value of N, then the comparison is
between a signed and an unsigned value, leading to potential
wrap-around. Casting N to SSize_t merely hides any compiler warnings,
thus failing to alert the caller to a problem with their code. In
addition, where sizeof(N) > sizeof(SSize_t), the cast may truncate N,
again leading to false negatives. The solution is to remove the cast,
and let the caller deal with any compiler warnings that result.
3) Similarly, casting stack_grow()'s N arg can hide any warnings issued by
e.g. -Wconversion. So remove it. It still does the wrong thing if the
caller uses a non-signed type (usually a panic in stack_grow()), but
coders have slightly more chance of spotting issues at compile time
now.
4) If sizeof(N) > sizeof(SSize_t), then the N arg to stack_grow() may get
truncated or sign-swapped. Add a test for this (basically that N is too
big to fit in a SSize_t); for simplicity, in this case just set N to
-1 so that stack_grow() panics shortly afterwards. In platforms where
this can't happen, the test is constant folded away.
With all these changes, the macro now looks in essence like:
if ( n < 0 || PL_stack_max - p < n)
stack_grow(sp,p,
(sizeof(n) > sizeof(SSize_t) && ((SSize_t)(n) != n) ? -1 : n));
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- linkify references to sections
- use EXTEND(SP, n) and PUSHs() instead of XPUSHs() where applicable
and update prose to match
- add POPu, POPul and POPpbytex to the "complete list of POP macros"
and clarify the documentation for some of the existing entries, and
a note about side-effects
- add API documentation for POPu and POPul
- use ERRSV more efficiently
- approaches to thread-safety storage of SVs.
- minor updates
|
| |
|
|
|
| |
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.
|
| | |
|
