| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
padav is leaving an arrayref on the stack when producing the return value for an
lvalue sub. But when this is in an argument list it really should be a array,
not a ref. So, in leavesublv I check for this case and expand the arrayref to
an array.
|
| |
|
|
| |
Nothing outside the core was using this macro.
|
| | |
|
| |
|
|
|
| |
Calling a subref whose value was PL_sv_yes, and without args,
failed to pop an entry off the mark stack
|
| |
|
|
|
| |
sv_utf8_upgrade_nomg() may reallocate the stack via sv_recode_to_utf8()
if 'use encoding' is in effect, causing stack pointer corruption.
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 0fe688f528b0e1b5bef6fb30d5e45316430e8a41, except
for the tests.
It is no longer necessary, as of change 2acc3314e31a9. Another reason
for this revert is that doing so fixes bug #77812, or at least it
would if 2acc3314e31a9 had not fixed that, too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactoring of the grammar around statements. New production <barestmt>
encompasses a statement without label. It includes all statement types,
including declarations, with no unnecessary intermediate non-terminals.
It generates an op tree for the statement's content, with no leading
state op. The <fullstmt> production has just one rule, consisting of
optional label followed by <barestmt>. It puts a state op on the front
of the statement's content ops.
To support the regular statement op structure, the op sequence for for(;;)
loops no longer has a second state op between the initialisation and
the loop. Instead, the unstack op type is slightly adapted to achieve
the stack clearing without a state op.
The newFOROP() constructor function no longer generates a state op,
that now being the job of the <fullstmt> production. Consequently it
no longer takes a parameter stating what label is to go in the state op.
This brings it in line with the other op constructors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The former behaviour of map and grep was to never free any temps.
Thus for large lists (and even worse, nested maps), the tmps stack could
grow very large. For all cases expect list-context map, the fix is easy:
just do a FREETMPS at the end of each iteration.
The list-context map however, needs to accumulate a list of temporaries
over the course of the iterations, and finally return that list to the
caller (which is responsible for freeing them). We get round this by, at
the end of each iteration, directly manipulating the tmps stack to free
everything *except* the values to be returned. To make this efficient,
we splice in the returned tmp items at the base of the stack frame, move
PL_tmps_floor above them, then do a FREETMPS (so they may appear twice on
the temps stack, but initially only get freed once).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test from t/op/gv.t was added by change 22315/4ce457a6:
{
# test the assignment of a GLOB to an LVALUE
my $e = '';
local $SIG{__DIE__} = sub { $e = $_[0] };
my $v;
sub f { $_[0] = 0; $_[0] = "a"; $_[0] = *DATA }
f($v);
is ($v, '*main::DATA');
my $x = <$v>;
is ($x, "perl\n");
}
That change was the one that made glob-to-lvalue assignment work to
begin with. But this test passes in perl version *prior* to that
change.
This patch fixes the test and adds tests to make sure what is assigned
is actually a glob, and not just a string.
It also happens to fix the stringification bug. In doing so, it essen-
tially ‘enables’ globs-as-PVLVs.
It turns out that many different parts of the perl source don’t fully
take this into account, so this patch also fixes the following to work
with them (I tried to make these into separate patches, but they are
so intertwined it just got too complicated):
• GvIO(gv) to make readline and other I/O ops work.
• Autovivification of glob slots.
• tie *$pvlv
• *$pvlv = undef, *$pvlv = $number, *$pvlv = $ref
• Duplicating a filehandle accessed through a PVLV glob when the
stringified form of the glob cannot be used to access the file
handle (!)
• Using a PVLV glob as a subroutine reference
• Coderef assignment when the glob is no longer in the symbol table
• open with a PVLV glob for the filehandle
• -t and -T
• Unopened file handle warnings
|
| |
|
|
|
|
|
|
| |
When calling the destructors for IO objects embedded in arena GVs,
process PL_defoutgv and PL_stderrgv last. Yes, the test suite
expects STDOUT to still work at this point. Indeed, one test in ref.t
calls print from STDOUT's destructor (which is why pp_print needed a
slight tweak to handle a null GV properly).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix for #31865: weird results from reverse( %x = reverse %h )
Basically, anything of the form
@a = %h = (list with some duplicate keys)
may have left @a containing weird and/or freed values.
There was a partial fix for this with ca65944e, but it was broken
(it did one big block move on the stack at the end to remove duplicates,
but duplicates weren't necessarily all in one block.)
The new fix is a two-stage process. First, while pulling key/value pairs
of the stack and assigning them to the hash, each key/val pair is written
back to the stack - possibly at a lower position if there are duplicates to
be skipped.
Finally at the end if any duplicates have been detected, then in list
context, a single pass is made through the stack, and for each key/val
pair, the key is looked up and the val on the stack is overwritten with
the new value (replacing possibly freed or other garbage values).
|
| |
|
|
|
|
|
|
|
| |
The
if (( !global
rather than
if ( (!global
made it hard to follow the precedence.
Tidy up the rest of the expression while I'm at it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Partial fix for [perl #77084]. Sometimes pp_match makes a copy of the
original SV's string for the later use of $1 et al; in particular if the
SV is TEMP (so will soon go away).
Make it do the same if the SV is overloaded, as the string return is most
certainly temporary!
(Also tweak the tests to make them more likely to fail on badness by
creating new stings that will likely reallocate freed buffer).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are left from PERL_OBJECT, which was an implementation of
multiplicity using C++ objects. PERL_OBJECT was removed in 5.8, but the
macros seem to have been cargo-culted all over the core (including in
places where they would have been inappropriate originally). Since they
now do exactly nothing, it's cleaner to remove them.
I have left the definitions in perl.h, under #ifndef PERL_CORE, since
some CPAN XS code uses them (also often incorrectly). I have also left
STATIC alone, since it seems potentially more useful and is much more
ingrained.
The only appearance of these macros this patch doesn't touch is in
Devel-PPPort, because that's a CPAN module.
|
| |
|
|
|
|
|
| |
holds back a fix for RT#67838.
This commit allows PP lvalue subs to return temps with set magic
and removes TODO from tests.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The attached patch teaches pp_leavesublv about kine.
For the record, a binary search points its digit at:
From: Nicholas Clark <nick@ccl4.org>
Date: Mon, 6 Jun 2005 09:08:45 +0000 (+0000)
Subject: Shared hash key scalars can be safely copied as shared hash key scalars
Shared hash key scalars can be safely copied as shared hash key scalars all the time.
|
| |
|
|
|
|
|
|
| |
The problem here is that globs are scalars and the = operator can only
distinguish between scalar and glob assignments by the flags on the
glob. It only sees the return value of *{}, not the *{} itself. We can
fix this by having the pp_sassign look for a rv2gv (*{}) on its LHS,
to decide what type of assignment to do.
|
| |
|
|
| |
Brought to you by the campaign for the elimination of strlen().
|
| |
|
|
| |
in t/op/readline.t
|
| |
|
|
| |
make it clearer what type of concat each code branch handles
|
| |
|
|
|
|
|
| |
There was a piece of code in pp_concat who's job it was to determine the
UT8ness of the LHS, and it did it in a heavy-handed way to cope with the
special case of a regexp (which is an RV pointing to REGEXP which might
be UTF8)
|
| |
|
|
|
| |
This reduces object code size, reducing CPU cache pressure on the non-exception
paths.
|
| |
|
|
|
|
| |
pp_entersub checked for ROK *before* calling magic. If the tied scalar
already had ROK set (perhaps from a previous time), then get magic (and
hence FETCH) wasn't called.
|
| |
|
|
|
| |
This better represents its current role as specifically delaying magic on
@ISA as opposed to a general array magic delay mechanism.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 90630e3c741716305d7f1da4df5eab5c1bee42cc.
This fix turns out to be wrong, and also made ($<,$>)=(...) fail
(RT #75212).
The original problem was a SEGV in av_clear(). This was mis-diagnosed
as recursive PL_delaymagic issue, and the fix was to temprarily reset
PL_delaymagic to zero. This stopped the mg_set() of $> and $> being
delayed.
The real problem was that mg_free wasn't clearing the [GSR]MG flags
after freeing xmg_magic. This was independently fixed by commit
68f8932eb570af656553ed44c11a23f0a216a3ec.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The previous commit made various ops such as rv2av unconditionally do
an SvGETMAGIC(). Under some circumstances this could cause a double
mg_get() (and hence double FETCH etc). In particular, when the
proceeding op was something like aelem with OPpDEREF, the aelem would
call vivify_ref(), which would call magic. So in peep(), mark
OP_RV2[SAH]V ops with the new OPpDEREFed flag if the preceding op was
OPpDEREF. Then use this flag to avoid a second dose of magic.
Note that RV2GV probably needs this flag too, but there weren't any
spare private flag bits left for that op (I think).
|
| |
|
|
|
| |
This is just like bug 68192, except in this case it’s a different set
of operators that have had this problem for much longer.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes s/// so that it doesn't act destructively on its target.
Instead it returns the result of the substitution (or the original string if
there was no match).
In addition this patch:
* Adds a new warning when s///r happens in void context.
* Adds a error when you try to use s///r with !~
* Makes it so constant strings can be bound to s///r with =~
* Adds documentation.
* Adds some tests.
* Updates various debug code so it knows about the /r flag.
* Adds some new 'r' words to B::Deparse.
|
| |
|
|
|
|
|
| |
6f1401dc2acd2a2b85df22b0a74e5f7e6e0a33aa was over-enthusiastic
on removing redundant code in the comparison ops. This code was only used
on 64-bit #ifdef branches which is why I failed to spot it earlier.
So restore that code!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In most places, ops checked their args for overload *before* doing
mg_get(). This meant that, among other issues, tied vars that
returned overloaded objects wouldn't trigger calling the
overloaded method. (Actually, for tied and arrays and hashes, it
still often would since mg_get gets called beforehand in rvalue
context).
This patch does the following:
Makes sure get magic is called first.
Moves most of the overload code formerly included by macros at the
start of each pp function into the separate helper functions
Perl_try_amagic_bin, Perl_try_amagic_un, S_try_amagic_ftest,
with 3 new wrapper macros:
tryAMAGICbin_MG, tryAMAGICun_MG, tryAMAGICftest_MG.
This made the code 3800 bytes smaller.
Makes sure that FETCH is not called multiple times. Much of this
bit was helped by some earlier work from Father Chrysostomos.
Added new functions and macros sv_inc_nomg(), sv_dec_nomg(),
dPOPnv_nomg, dPOPXiirl_ul_nomg, dPOPTOPnnrl_nomg, dPOPTOPiirl_ul_nomg
dPOPTOPiirl_nomg, SvIV_please_nomg, SvNV_nomg (again, some of
these were based on Father Chrysostomos's work).
Fixed the list version of the repeat operator (x): it now only
calls overloaded methods for the scalar version:
(1,2,$overloaded) x 10
no longer erroneously calls
x_method($overloaded,10))
The only thing I haven't checked/fixed yet is overloading the
iterator operator, <>.
|
| |
|
|
|
|
|
|
|
|
| |
When the replacement is in utf8, there was failure to upgrade the result
when the source and the pattern weren't in utf8. This simply checks
that when there is a match that will lead to the replacement being done.
It then does the upgrade. If this led to changes in the source, we redo
the match because pointers to saved buffers could have changed. There
may be other cases where we don't need to redo the match, but I don't
know the code well-enough to easily figure it out.
|
| |
|
|
|
|
| |
Scalar assignment to array elements already does this. (As does all other
scalar assignment, and list assignment to hashes.) Prior to 4c8f17b905f2
(change 7867) list assignment to arrays did steal temps.
|
| |
|
|
|
|
|
|
|
| |
4c8f17b905f2 (change 7867) took the approach of a special case in sv_setsv()
when PL_op indicated that the current OP was OP_AASSIGN. The problem is in one
part of pp_aassign, where it was using sv_mortalcopy() on values that were
correctly marked as temporaries, but also still needed later. Hence a more
targetted solution is to avoid that call, and to instead use API calls that
will not steal temporaries.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fix 2d961f6deff7 for RT #5475 included a mechanism for the early
calling of get magic on something like
$tied[0];
so that even though the element is used in void context, we still call
FETCH. Some people seem to rely on this.
However, the call to mg_get() didn't distinguish between a tiedelem
member retrieved from a tied array/hash, and a tiedscalar element
retrieved from a plain array/hash. In the latter case, the S_GSKIP
protection mechanism doesn't apply and a simple $foo = $h{tiedelem}
generated two calls to FETCH.
Fix this by only calling mg_get() on the element if it came from a *tied*
array/hash.
A side-effect of this fix is that the following no longer calls FETCH:
my @plain_array;
tie $plain_array[0], ....; # element 0 is now a tied scalar
$plain_array[0]; # void context: no longer calls FETCH.
This required one test in op/tie.t to be fixed up, but in general I think
this is a reasonable compromise.
|
| |
|
|
|
|
|
|
|
| |
With the move of PERL_ASYNC_CHECK() out from the runloop to control ops,
infinite loops became truely infinite, as their optree has no control ops.
Hence add a PERL_ASYNC_CHECK() to pp_unstack to ensure signals will be
dispatched.
Bug noticed by Jerry Hedden.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
For the typical code this gives a 5% speedup, and removes the cost of "safe
signals". Tight looping code will show less gains, but should never be slower.
Subtle bugs might remain - there might be constructions that enter the runloop
(where signals used to be dispatched) but don't contain any PERL_ASYNC_CHECK()
calls themselves.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nasty code like the following results in PL_defoutgv not pointing
to a valid GV:
my $x = *STDERR; select($x); $x = 1;
This causes all sorts of SEGVs when PL_defoutgv is subsequently accessed,
because most code assumes that it has a valid gv_gp pointer. It also
turns out that PL_defoutgv is under-tested; for example, temporarily
hacking pp_close to make an arg-less close() croak didn't cause any
minitest failures.
Add a new test file that does some basic testing of a bad PL_defoutgv,
and fix all the obvious badness in accessing it.
This also fixes #20727, which although ostensibly a tie bug, was due to
PL_defoutgv pointing to a tiedelem scalar, and fun like that described
above happening.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
magical array and hash elements; e.g. the following looped infinitely:
$h{tainted_element} =~ /..../g
There are two side-effects of this fix.
First, MGf_GSKIP has been extended to work on tied array
elements as well as hash elements. This is the mechanism that skips all
but the first tied element magic gets until after the next set.
Second, rvalue hash/array element access where the element has get magic,
now directly returns the element rather than a mortal copy.
The root cause of the bug was code similar to the following in pp_alem,
pp_aelemfast, pp_helem and pp_rv2av:
if (!lval && SvGMAGICAL(sv)) /* see note in pp_helem() */
sv = sv_mortalcopy(sv);
According to the note, this was added in 1998 to make this work:
local $tied{foo} = $tied{foo}
Since it returns a copy rather than the element, this make //g fail.
My first attempt, a few years ago, to fix this, took the approach that
the LHS of the bind should be made an lvalue in the presence of //g, since
it now modifies its LHS; i.e.
expr =~ // expr is rvalue
expr =~ s/// expr is lvalue
expr =~ //g expr was rvalue, I proposed to change it to lvalue
Unfortunately this fix broke too much stuff (stuff that was arguably
already broken, but it upset people). For example, f() ~= s////
correctly gives the error
Can't modify non-lvalue subroutine call
My fix extended f() =~ //g to give the same error. Which is reasonable,
because the g isn't doing what you want. But plenty of people had code that
only needed to match once and the g had just been cargo-culted. So it
broke their working code. So lets not do this.
My new approach has been to remove the sv_mortalcopy(). It turns out
that this is no longer needed to fix the local $tied{foo} issue.
Presumably that went away as a side-effect of my container/value magic
localisation rationalisation of a few years ago, although I haven't
analysed it - just noted that the tests still pass (!). However, an issue
with removing it is that mg_get() no longer gets called. So a plain
$tied_hash{elem};
in void context no longer calls FETCH(). Which broke some tests and might
break some code. Also, there's an issue with the delayed calling of magic
in @+[n] and %+{foo}; by the time the get magic is called, the original
pattern may have gone out of scope.
The solution is to simply replace the original
sv = sv_mortalcopy(sv);
with
mg_get(sv);
This then caused problems with tied array FETCH() getting called too much.
I fixed this by extending the MGf_GSKIP mechanism to tied arrays as well
as hashes. I don't understand why tied arrays have always been treated
differently than tied hashes, but unifying them didn't seem to break
anything (except for a Storable test, whose comment indicated that the
test's author thought FETCH() was being called to often anyway).
|
| |
|
|
|
|
|
|
|
|
| |
It's conflicting with an established pattern in XS code, working around the
inability of the XS SCOPE: keyword to actually provide anything useful.
The minor amount of extra debugging it gives here is not worth the external
trouble it causes.
Revisit this once we can provide a meaningful option to disable the
ENTER/LEAVE around XSUBs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
matches
The match vars are associated with the regexp that last matched
successfully. In the case of $str =~ $qr or /$qr/, since the $qr could
be used in multiple scopes that need their own sets of match vars, the
$qr is cloned by Perl_reg_temp_copy as of change 30677/28d8d7f. This
happens in pp_regcomp before pp_match has stringified the LHS, hence the
bug. In short, /$gror/ is not equivalent to
($which = !$which) ? /$gror/ : /$gror/, which is weird.
Attached is a patch, which admittedly is a hack, but fixes this
particular side effect of what is probably a bad design, by stringifying
the LHS in pp_regcomp, and having pp_match skip get-magic in such cases.
A real fix far exceeds my capabalities, and would also be very intrusive
according to
<http://www.nntp.perl.org/group/perl.perl5.porters/2007/03/msg122415.html>.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of returning a(nother) reference to the (pre-compiled) regexp in the
optree, use reg_temp_copy() to create a copy of it, and return a reference to
that. This resolves issues about Regexp::DESTROY not being called in a timely
fashion (the original bug tracked by RT #69852), as well as bugs related to
blessing regexps, and of assigning to regexps, as described in correspondence
added to the ticket.
It transpires that we also need to undo the SvPVX() sharing when ithreads
cloning a Regexp SV, because mother_re is set to NULL, instead of a cloned
copy of the mother_re. This change might fix bugs with regexps and threads in
certain other situations, but as yet neither tests nor bug reports have
indicated any problems, so it might not actually be an edge case that it's
possible to reach.
|
| |
|
|
|
|
|
|
|
|
|
| |
As the core no longer needs this fixed string in more than one place, it seems
daft to go to the overhead (and cost) of making it public in case any module
wants to use it. Modules that do want to use it should provide their own inline
copy in future.
Also restore the visible global PL_no_symref back to the original format
specification (of 5.10.0 and earlier), as an extra %s has the potential to
cause SEGVs or worse if not spotted at compile time.
|
| |
|
|
| |
ENTER/LEAVE when debugging is enabled
|
| |
|
|
|
|
| |
Wasted a few minutes more than necessary trying to work out why the
string was truncated when in fact it was the error message that was
truncating the string.
|
| |
|
|
|
|
|
| |
Replace ckWARN{,2,3,4}() && Perl_warner() with it, which trades reduced code
size (about 0.2%), for 1 more function call if warnings are not enabled.
However, if we're now in the L1 or L2 cache when we weren't previously, that's
still going to be a speed win.
|
| |
|
|
| |
Signed-off-by: Yves Orton <demerphq@gemini.(none)>
|
| | |
|
| | |
|
