| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
In a few places, SVs can be created more efficiently or new SVs
can be assigned to more efficiently. Small changes included:
* Use sv_setpvn_fresh instead of sv_setpvn
* Use sv_mortalcopy_flags instead of sv_newmortal + sv_setsv_flags
* newSVsv_flags instead of newSV + sv_setsv_flags
* sv_newmortal instead of sv_2mortal(newSV(0))
* Remove a SvGROW(sv, 257) following a newSV(257)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move some other variable declarations into a tighter scope, and initialise
variables at the point of declaration where possible.
With the recent changes, the function consists of a 4-way switch inside a
loop, where each iteration of the loop will take the same case in the
switch. This implies a branch taken on each iteration of the loop, which
is less efficient than the alternative structure of taking the branch once
and then looping.
However, the way the code is structured (particularly how two of the cases
share code, by jumping sideways), means that rewriting it to "switch first"
structure would not be clearer (and likely would also be hard to get
right). Hence it seems better to let a compiler optimiser choose what is
best. However, it might not realise that CxTYPE(cx) won't be changed, even
as a side effect of any function called by this code. Hence hoist it into a
constant variable to make this unequivocal.
|
|
|
|
|
| |
This commit provides the runtime changes needed to iterate for loops over
two or more variables.
|
|
|
|
|
|
|
| |
Add braces and indent a block that will become a `for` loop in the next
commit. With the exception of these and merging 3 opening braces onto the
`if` or `else` on the previous lines, this commit is purely a whitespace
change.
|
| |
|
|
|
|
|
| |
Otherwise it will return wrong results, unless other code happens to
have iterated over %ENV. This bug has probably existed forever.
|
|
|
|
|
|
|
|
|
|
|
| |
These are identified as being static shared COW strings whose string
buffer points directly at PL_Yes / PL_No
Define sv_setbool() and sv_setbool_mg() macros
Use sv_setbool() where appropriate
Have sv_dump() annotate when an SV's PV buffer is one of the PL_(Yes|No) special booleans
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code that handled hashes and arrays was removed by commit 2517717a8902:
The cases for SVt_PVAV and SVt_PVHV in pp_defined are unreachable.
Remove them, and hit to the C compiler that it's unlikely that someone used
`defined` on a subroutine.
These have been unreachable since `defined @array` and `defined %hash`
became syntax errors. Whilst the same PP code is used for // and //=,
expressions such as`@a // @b` put the left array (or hash) in scalar
context, meaning that it always returns a define value.
(Should we warn on these?)
However, it turns out that that the removed code was reachable by XS code
generating data structures that would be "illegal" in pure Perl (eg also
triggering "Bizarre copy of ..." errors). Hence with -DDEBUGGING, add logic
to report problematic cases, instead of silently continuing with changed
behaviour.
|
|
|
|
|
|
| |
We know how many pairs of keys/values are on the stack, so pre-extend the
hash to the appropriate size, instead of letting the hash needlessly re-size
one or more times during the assignment loop.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Remove them, and hit to the C compiler that it's unlikely that someone used
`defined` on a subroutine.
These have been unreachable since `defined @array` and `defined %hash`
became syntax errors. Whilst the same PP code is used for // and //=,
expressions such as`@a // @b` put the left array (or hash) in scalar
context, meaning that it always returns a define value.
(Should we warn on these?)
|
| |
|
|
|
|
| |
AvREIFY_only() is about to be applied
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This just detabifies to get rid of the mixed tab/space indentation.
Applying consistent indentation and dealing with other tabs are another issue.
Done with `expand -i`.
* vutil.* left alone, it's part of version.
* Left regen managed files alone for now.
|
|
|
|
|
|
|
|
| |
Remove a bit of a hack done by me 2 years ago to shut up a compiler warning
which did a cast to RW of a constant string.
Since the field which the const string is assigned to is never modified,
just make that field const instead.
|
|
|
|
|
|
|
| |
I was never happy with this short form, and other people weren't either.
Now that most things are better expressed in terms of av_count, convert
the few remaining items that are clearer when referring to an index into
using the fully spelled out form
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GH #16685
In
@a = ($x, undef, undef) = (1))
@a should have 3 elements. v5.25.6-79-gb09ed995ad broke this and was
returning one element.
The fix is simple: that previous commit made it so that elements were
pushed back onto the stack only if they weren't immortal, so
&PL_sv_undef was getting skipped. Make it so they always are.
|
| |
|
|
|
|
|
| |
It only does anything under PERL_GLOBAL_STRUCT, which is gone.
Keep the dNOOP defintion for CPAN back-compat
|
|
|
|
|
| |
Mostly in comments and docs, but some in diagnostic messages and one
case of 'or die die'.
|
|
|
|
|
|
|
|
| |
This fixes #17612
This adds an inline function to pp_hot to be called to determine if
debugging info should be output or not, regardless of whether it comes
from -Dr, or from a 'use re Debug' statement
|
|
|
|
| |
This makes things easier to read.
|
|
|
|
|
|
|
| |
This replaces strchr("list", c) calls throughout the core. They don't
work properly when 'c' is a NUL, returning the position of the
terminating NUL in "list" instead of failure. This could lead to
segfaults or even security issues.
|
|
|
|
|
|
|
|
| |
Essentially the same code was being used in three places, and had
undefined C behavior for some inputs.
This consolidates the code into one inline function, and rewrites it to
avoid undefined behavior.
|
|
|
|
| |
These are bogus warnings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RT #133789
In the path taken through pp_multiconcat() when one or more args have
side-effects such tieing or overloading, multiconcat has to decide
whether to just return the result of all the concatting as-is, or to
first assign it to an expression or variable if the op includes an
implicit assign (such as $lex = x.y.z or $a[0] = x.y.z).
The code was getting this right for those two cases, and was also
getting it right for the append cases ($lex .= x.y.z and $a[0] .= x.y.z),
which don't need assigns. But for the bare case (x.y.z) it was assigning
to the op's targ as well as returning the value. Hence leaking a
reference until destruction of the sub and its pad.
This commit stops the assign in that last case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A couple of places in the overload code do SvPADMY(TARG) to decide
whether this is a normal op like ($x op $y), where the targ will have
SVs_PADTMP set, or a lexical assignment like $lex = ($x op $y) where the
assign has been optimised away and the op is expected to directly assign
to the targ which it thinks is a PADTMP but is really $lex.
Since the SVs_PADMY flag was eliminated a while ago, SvPADMY() is just
defined as !(SvFLAGS(sv) & SVs_PADTMP). Thus the overload code is
relying on the absence of a PADTMP flag in the target to deduce that the
OPpTARGET_MY optimisation is in effect. This seems to work (at least for
the code in the test suite), but can't be regarded as robust. This
commit removes each SvPADMY() test and replaces it with the twin
if ( (PL_opargs[PL_op->op_type] & OA_TARGLEX)
&& (PL_op->op_private & OPpTARGET_MY))
tests.
|
|
|
|
|
|
|
|
| |
PERL_OP_PARENT is the new reality, leaving the pre-processor
checks is more confusing that anything else.
I left the test in perl.c for consistency with the other checks in that
code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit replaces all instances of code that looks like this:
uv = (iv == IV_MIN) ? (UV)iv : (UV)(-iv)
with simpler and more optimal:
uv = -(UV)iv
While -iv indeed results in an undefined behaviour when iv == IV_MIN,
-(UV)iv is perfectly well defined and does the right thing.
C standard guarantees that the result of (UV)iv (for negative iv) is
equal to iv + UV_MAX + 1 (see 6.3.1.3, paragraph 2 in C11). It also
guarantees that the result of -uv is UV_MAX - uv + 1 (6.2.5,
paragraph 9).
That means that the result of -(UV)iv is UV_MAX - (iv + UV_MAX + 1) + 1
which is equal to -iv for *all* possible negative values of iv.
[perl #133677]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RT #133558
Due to what appears to be a compiler bug on AIX (or perhaps it's
undefined behaviour which happens to work on other platforms), this line
of code in pp_iter():
inc = 1 - (PL_op->op_private & OPpITER_REVERSED);
was setting inc to 4294967295 rather than to the expected -1 (inc was a
64-bit signed long).
Fix it with a couple of judicious (IV) casts (which ought to be a NOOP).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 7c114860c0fa8ade5e00a4b609d2fbd11d5a494c introduced an optimisation
in pp_iter(). Before the optimisation, pp_iter() pushed either &PL_SV_yes or
&PL_sv_no to the stack, and returned the op_next in the obvious way.
The optimisation takes advantage of the fact that the op_next of an OP_ITER
always points to an OP_AND node, so pp_iter() now directly jumps to either
the op_next or the op_other of the OP_AND as appropriate.
The commit message for the optimisation also says this:
It's possible that some weird optree-munging XS module may break this
assumption. For now I've just added asserts that the next op is OP_AND
with an op_ppaddr of Perl_pp_and; if that assertion fails, it may be
necessary to convert pp_iter()s' asserts into conditional statements.
However, Devel::Cover does change the op_ppaddr of the ops it can see, so
the assertions on op_ppaddr were being tripped when Devel::Cover was run
under a -DDEBUGGING Perl. But even if the asserts didn't trip, skipping the
OP_AND nodes would prevent Devel::Cover from determining branch coverage in
the way that it wants.
This commit converts the asserts into conditional statements, as outlined in
the commit message above, and undoes the optimisation when the op_ppaddr
doesn't match.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC due to a bug doesn't merge identicals between .o'es or discard these
vars and their contents.
MEM_WRAP_CHECK_2 has never been used outside of core according to cpan grep
MEM_WRAP_CHECK_2 was removed on the "have PERL_MALLOC_WRAP" branch in
commit fabdb6c0879 "pre-likely cleanup" without explination, probably bc
it was unused. But MEM_WRAP_CHECK_2 was still left on the "no
PERL_MALLOC_WRAP" branch, so remove it from the "no" side for tidyness
since it was a mistake to leave it there if it was removed from the "yes"
side of the #ifdef.
Add MEM_WRAP_CHECK_s API, letter "s" means argument is string or static.
This lets us get rid of the "%s" argument passed to Perl_croak_nocontext at
a couple call sites since we fully control the next and only argument and
its guaranteed to be a string literal. This allows merging of 2
"Out of memory during array extend" c strings by linker now.
Also change the 2 op.h messages into macros which become string literals
at their call sites instead of "read char * from a global char **" which
was going on before.
VC 2003 32b perl527.dll section size before
.text name
DE503 virtual size
.rdata name
4B621 virtual size
after
.text name
DE503 virtual size
.rdata name
4B5D1 virtual size
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RT #132793, RT #132801
In something like $x .= "$overloaded", the $overloaded stringify method
wasn't being called.
However, it turns that the existing (pre-multiconcat) behaviour is also
buggy and inconsistent. That behaviour has been restored as-is.
At some future time, these bugs might be addressed.
Here are some comments from the new tests added to overload.t:
Since 5.000, any OP_STRINGIFY immediately following an OP_CONCAT
is optimised away, on the assumption that since concat will always
return a valid string anyway, it doesn't need stringifying.
So in "$x", the stringify is needed, but on "$x$y" it isn't.
This assumption is flawed once overloading has been introduced, since
concat might return an overloaded object which still needs stringifying.
However, this flawed behaviour is apparently needed by at least one
module, and is tested for in opbasic/concat.t: see RT #124160.
There is also a wart with the OPpTARGET_MY optimisation: specifically,
in $lex = "...", if $lex is a lexical var, then a chain of 2 or more
concats *doesn't* optimise away OP_STRINGIFY:
$lex = "$x"; # stringifies
$lex = "$x$y"; # doesn't stringify
$lex = "$x$y$z..."; # stringifies
|
|
|
|
|
|
|
|
|
|
|
| |
After the previous commit, dsv is always the same as targ,
so relace all uses of 'dsv' with 'targ', and rename the 'dsv_pv' var
to 'targ_pv'.
Also rename a limited scope var from 'targ_pv' to targ_buf' as that
name is now being used for dsv_pv.
Should be no functional changes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way pp_multiconcat handles things like tieing and overloading
doesn't work very well at the moment. There's a lot of code to handle
edge cases, and there are still open bugs.
The basic algorithm in pp_multiconcat is to first stringify (i.e. call
SvPV() on) *all* args, then use the obtained values to calculate the total
length and utf8ness required, then do a single SvGROW and copy all the
bytes from all the args.
This ordering is wrong when variables with visible side effects, such as
tie/overload, are encountered. The current approach is to stringify args
up until such an arg is encountered, concat all args up until that one
together via the normal fast route, then jump to a special block of code
which concats any remaining args one by one the "hard" way, handling
overload etc.
This is problematic because we sometimes need to go back in time. For
example in ($undef . $overloaded), we're supposed to call
$overloaded->concat($undef, reverse=1)
so to speak, but by the time of the method call, we've already tried to
stringify $undef and emitted a spurious 'uninit var' warning.
The new approach taken in this commit is to:
1) Bail out of the stringify loop under a greater range of problematical
variable classes - namely we stop when encountering *anything* which
might cause external effects, so in addition to tied and overloaded vars,
we now stop for any sort of get magic, or any undefined value where
warnings are in scope.
2) If we bail out, we throw away any stringification results so far,
and concatenate *all* args the slow way, even ones we're already
stringified. This solves the "going back in time" problem mentioned above.
It's safe because the only vars that get processed twice are ones for which
the first stringification could have no side effects.
The slow concat loop now uses S_do_concat(), which is a new static inline
function which implements the main body of pp_concat() - so they share
identical code.
An intentional side-effect of this commit is to fix three tickets:
RT #132783
RT #132827
RT #132595
so tests for them are included in this commit.
One effect of this commit is that string concatenation of magic or
undefined vars will now be slower than before, e.g.
"pid=$$"
"value=$undef"
but they will probably still be faster than before pp_multiconcat was
introduced.
|
|
|
|
|
|
|
| |
Create an inline static function which implements the body of pp_concat(),
then replace pp_concat()'s body with a call to it.
Shortly, we'll use this function in pp_multiconcat() too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes #132729 in the specific case where a nonexistent
element within a sparse array is passed to a subroutine.
Prior to this commit,
some_sub($sparse_array[$n])
where $n <= $#sparse_array and the element does not exist, would exhi-
bit erroneous behaviour if some_sub shifted or unshifted the original
@sparse_array. Any ‘holes’ (nonexistent elements) in the array would
show up in @_ as deferred element (defelem) scalars, magic scalars
that remember their index in the array. This index is not updated and
gets out of synch when the array is shifted.
This commit fixes the bug for elements within the array by using the
new ‘nonelem’ magic introduced a few commits ago. It stores within
the array a magic scalar that is marked as being nonexistent.
It also reduced the number of scalars that need to be created if such
a sub call happens repeatedly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes #132729 in the particular instance where an XSUB is
called via ampersand syntax when @_ has ‘holes’, or nonexistent ele-
ments, as in:
@_ = ();
$_[1] = 1;
&xsub;
This means that if the XSUB or something it calls unshifts @_, the
first argument passed to the XSUB will now refer to $_[1], not $_[0];
i.e., as of this commit it is correctly shifted over. Previously, a
‘defelem’ was used, which is a magical scalar that remembers its index
in the array, independent of whether the array was shifted.
In addition, the old code failed to mortalize the defelem, so this
commit fixes a memory leak with the new ‘non-elem’ mechanism (a spe-
cially-marked element stored in the array itself).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To avoid having to create deferred elements every time a sparse array
is pushed on to the stack, store a magic scalar in the array itself,
which av_exists and refto recognise as not existing.
This means there is only a one-time cost for putting such arrays on
the stack.
It also means that deferred elements that live long enough don’t
start pointing to the wrong array entry if the array gets shifted (or
unshifted/spliced) in the mean time. Instead, the scalar is already
in the array, so it cannot lose its place. This fix only applies
when the array as a whole is pushed on to the stack, but it could be
extended in future commits to apply to other places where we currently
use deferred elements.
|
|
|
|
|
|
|
| |
As Zefram pointed out, I left in a piece of code that caused one
branch to continue to behave as before. The change was ineffective
and the tests happened to be written in such a way as to take the
other branch.
|
|
|
|
|
|
|
|
|
|
| |
6661956a2 was a little too powerful, and, in addition to fixing the
bug that @_ did not properly alias nonexistent elements, also broke
other uses of nonexistent array elements. (See the tests added.)
This commit changes it so that putting @a on the stack does not vivify
all ‘holes’ in @a, but creates defelem (deferred element) scalars, but
only in lvalue context.
|
|
|
|
|
|
|
|
|
|
|
| |
When the elements of an array are put on the stack, by a padav, rv2av,
or padrange op, null pointers in the AvARRAY were being pushed as
&PL_sv_undef, which was OK in rvalue contexts but caused misbehaviour
in lvalue contexts. Change this to vivify these elements. There's no
attempt here to limit the vivification to lvalue contexts: the existing
op flags aren't enough to detect \(@a), and attempting to catch all
cases where a new flag needs to be set would be an error-prone process.
Fixes [perl #8910].
|
|
|
|
|
|
|
|
|
|
|
|
| |
pp_hot.c(930) : warning C4146: unary minus operator applied to unsigned type,
result still unsigned
Negating an unsigned STRLEN (aka Size_t) string length in this case will
never encounter a situation where the value is too big to be negated,
because at that point we have both the string and a grown buffer of at
least equal size in memory simultaneously, so targ_len < Size_t_MAX/2.
So just cast away the warning.
|
|
|
|
|
|
|
|
|
|
|
| |
Normally s/// returns a count of the number of iterations, but
as an optimisation, in boolean context it returns PL_sv_yes/PL_sv_zero
instead. But in the places where it decides which immortal var to return,
the number of iterations is always > 0, so PL_sv_zero never gets returned.
So skip testing whether iters > 0 and always just return PL_sv_yes.
(In non-boolean scalar context, it still returns the iteration count as
before.)
|