| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
In particular, distinguish between scope and context stack push/pops,
show depth of JUMPENV stack, and show STACKINFO push/pops
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the issue in the following:
use re 'taint';
$tainted =~ /(...)/;
# $1 now correctly tainted
$untainted =~ s/(...)/$1/;
# $untainted now incorrectly tainted
The problem stems from when $1 is updated.
pp_substcont, which is called after the replacement expression has been
evaluated, checks the returned expression for taintedness, and if so,
taints the variable being substituted. For a substitution like
s/(...)/x$1/ this works fine: the expression "x".$1 causes $1's get magic
to be called, which sets $1 based on the recent match, and is marked as
not tainted. Thus the returned expression is untainted. In the variant
s/(...)/$1/, the returned value on the stack is $1 itself, and its get
magic hasn't been called yet. So it still has the tainted flag from the
previous pattern.
The solution is to mg_get the returned expression *before* testing for
taintedness.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
| |
Change f6c77cf1bf4d7cb2c7a64dd7608120b471f84062 introduced
open($fh,"+<",undef)
but in the process stopped calling mg_get() on the third arg,
so tied values etc weren't getting processed
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under some circumstances the value returned by sprintf wasn't tainted,
even though its args were. While trying to fix this, I also came across
a second bug (which made fixing the first bug very confusing!) where
the TARG of the sprintf op, after getting tainted once, permanently
retained taint magic, which depending on circumstances, wasn't always set
to untainted (mg_len =0)
The original bug basically boiled down to parts of Perl_sv_vcatpvfn()
directly manipulating the target with SvGROW() / Copy(), which failed
to taint the target. Other parts used sv_catsv(), which did. So for
example:
"%s%s" failed, (only SvGROW)
"%s %s" worked (the space char was appended using sv_catsv).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
we'll ship in 5.12.0
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
rewrapping and module list updates
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
If random_r is disabled, so should srandom_r be. Changes in a distant
caused errors like:
"reentr.h", line 773.16: 1506-007 (S) "struct random_data" is undefined.
|
| |
|
|
| |
Add a comment explaining the problems with this function.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The original long-running test had a tighter limit for
sGMTIME_min and sLOCALTIME_min than the 2**47-1 limit
that was now hardcoded. Take the safe route.
|
| |
|
|
|
|
|
| |
was in Blead but is old than the current updated CPAN release. Comment
out a now deprecated 'use UNIVERSAL' line to prevent warnings from
production code. It's bad form to ship software that deprecates things
and then keeps using them and warning. Thanks to xdg++ for the spotting.
|
| |
|
|
| |
transition.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically:
1: / returns and NV where possible, only returning an integer if the dividend
is an integer larger than an NV can represent accurately, and integer
division is exact (ie no fractional part/remainder).
2: The test is performing $ref/1, intending it to be an identity operation
on the numeric value of the reference.
3: The test assumes that the return result of the division will be a number
that stringifies identically to the integer value of the reference.
The fails if both:
1: The system memory map is such that addresses are very large (ia64 does)
2: NVs are large enough to hold these addresses
because then the address becomes converted to an NV which has sufficient
decimal digits that stringification defaults to scientific notation.
Itanium Linux users the world over will be cheering because they can now
compile Perl with long doubles with confidence that all tests pass.
|
| |
|
|
| |
it's a recently added function, so removing it now does no harm.
|
| | |
|
| |
|
|
| |
(was missing from 0fa4a26596a4646f9aae1dcd199a2f30933e6f01)
|
| |
|
|
|
|
|
|
| |
The module encoding::warnings can be used to warn when two strings are
concatenated where one is utf8 and the other is not and contains
non-ASCII.
Note the existence of this in the pod documentation.
|
| |
|
|
|
|
|
|
|
|
|
| |
The code was added in 5.11.0 by
2990415a4519bc3988d7224ae15100c3e9e901ee
805b10112885d8868f21f8e860792d65e1e6c19d
but causes a big slowdown on most deparsing, due to the need
to walk the entire package tree looking for constant subs.
For more details, see
[perl #73052] Storable considerably slower at storing coderefs
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
f7461760003db2ce68155c97ea6c1658e96fcd27 improved the PL_check hook for
bareword subs, but broke the above module. This is Zefram's followup:
The issue is that speculative function lookups were leaving detritus
consisting of empty GVs in the stash. These didn't affect normal
functioning, but code that looks inside the stash could see them, and
code that makes unreliable assumptions about the format of the stash
can be broken. This is the same general mode of failure that we saw
with namespace::clean.
LinkedList-Single's failing test was using direct stash access poorly,
in a way that made for a poor test, quite apart from making too many
assumptions about stash structure. In the latest version of the package,
0.99.6, the test has been changed to a much better form, which actually
tests what it meant to and incidentally doesn't read the stash at all.
Although they don't affect normal functioning, the empty GVs shouldn't
be there. It's much like the upgraded constant subs, which we concluded
ought to be downgraded when the upgraded form is no longer required,
in order to save memory. The solution here is similar: delete the
empty GV when it is detected that a real GV is no longer required.
The present patch does this at the same time as checking for constant-sub
downgradability.
|
| | |
|
| | |
|
| | |
|
