| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Fixes a minor bug introduced in 4c74a7df3242aa95.
The underlying assumption of the XS AUTOLOAD implementation, that the fields
are unused, remains invalid.
|
| |
|
|
| |
997daa56862a0fc7 eliminated the need for passing these in.
|
| |
|
|
|
|
|
|
|
|
|
| |
case KEY_dbmopen in Perl_yylex() has always had special-case code to create
@AnyDBM_File::ISA, using GV_ADDMULTI. S_gv_magicalize_isa() [part of
Perl_gv_fetchpvn_flags()] has special case code to spot "AnyDBM_File::ISA"
being created with GV_ADDMULTI, and populate the variable if it is empty.
Grouping the special case code in one place makes more sense. Removing the
special case code from gv.c means that there is no longer a check clause in the
code path for *every* package's @ISA initialisation.
|
| |
|
|
|
|
|
|
| |
GvHV() and HvNAME() will both always already be set, as gv_fetchpvn_flags()
will initialise these as it walks the string in its initial loop to locate the
correct stash, then return early because name == name_end.
This code has been dead since it was added in 5.000.
|
| |
|
|
| |
Bug spotting and 1 fix by Jerry D. Hedden.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recently we’ve been getting assertions from gv.t like this:
Assertion failed: (SvTYPE(sv) != SVTYPEMASK), function Perl_sv_clear, file sv.c, line 5783.
This only happens in non-threaded builds and with PERL_DESTRUCT_LEVEL
set to 2 (as in make test).
These started with 13be902 (lvalue-to-glob assignment), but only
because of the tests it added.
The real cause turns out to be f746176, which introduced
gv_try_downgrade.
If a subroutine contains an op that references a downgradable GV, then
gv_try_downgrade, if called on that GV during global destruction,
*might* leave dangling pointers elsewhere; where exactly I wot not.
Since memory-saving operations such as this downgrading are questiona-
ble anyway durng global destruction, skip it, at least for now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first time gv_fetchfile is called for a particular file, it
creates the glob and, if debugging is on, creates an AV. If the glob
already exists (i.e., in subsequent calls), the AV is not created. The
attached patch moves the check for debugging mode and the creation of
the AV outside the if-block that checks whether the glob exists.
This bug seems to have existed for a very long time and has been
intermittent. It seems that many different things can change the order
in which #!perl -d and gv_fetchfile occur. Whether compilation options
affect it I do not know. I can reproduce it in 5.6.2, 5.8.[123456]
(non-threaded) and 5.11.3 (both threaded and non-threaded), but not
5.8.[789] or 5.10.[01] (threaded).
|
| |
|
|
| |
Ooops. I broke it with commit ad7cce9f36d376e55b45dd79ec28a7f795b5ae4e.
|
| |
|
|
|
| |
This way c++ compilers like us again, as we don't do jumps that skip
initialisations anymore.
|
| |
|
|
|
| |
Stop magic applied to $!, %SIG, et al. from applying to similarly-
named variables in other packages.
|
| |
|
|
| |
(follow-up to previous commit, fix for #76540)
|
| |
|
|
|
|
|
|
|
| |
gv_init() has name and len args, but newCONSTSUB() (which it calls)
doesn't have a len arg, so any trailing garbage in name gets used by
newCONSTSUB.
In the test case, this means that we end up attaching the const CV
to both the "FOO" and qq{FOO, "\\n";\n} GVs. So it gets freed twice.
|
| |
|
|
|
|
| |
Now that CvGV can sometimes be reference counted, stop people from directly
assigning to it (by using CvGV as an lvalue), and instead force them to use
CvGV_set()
|
| |
|
|
|
|
|
|
|
|
|
| |
Rather than making CvGV refcounted if the CV is anon, decide based on
whether the GV pointed to by CvGV holds a reference back to us. Normally
these two will be equivalent, but this way is more robust if people are
doing weird things.
Also spotted an error with cv_clone not clearing the CVf_CVGV_RC flag on
the newly cloned cv. This shouldn't normally matter as it will get set
shortly anyway, but best to keep things logically correct.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
after the recent commit 803f274831f937654d48f8cf0468521cbf8f5dff,
the CvGV field is sometimes reference counted. Since it was intended that
the reference counting would happen only for anonymous CVs, the CVf_ANON
flag was co-opted to indicate whether RC was being used. This is not
entirely robust; for example, sub __ANON__ {} is a non-anon sub which
points to the same GV used by anon subs, which while itself doesn't
directly break things, shows that the potential for breakage is there.
So add a separate flag just to indicate the reference count status of the
CvGV field.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each CV usually has a pointer, CvGV(cv), back to the GV that corresponds
to the CV's name (or to *foo::__ANON__ for anon CVs). This pointer wasn't
reference counted, to avoid loops. This could leave it dangling if the GV
is deleted.
We fix this by:
For named subs, adding backref magic to the GV, so that when the GV is
freed, it can trigger processing the CV's CvGV field. This processing
consists of: if it looks like the freeing of the GV is about to trigger
freeing of the CV too, set it to NULL; otherwise make it point to
*foo::__ANON__ (and set CvAONON(cv)).
For anon subs, make CvGV a strong reference, i.e. increment the refcnt of
*foo::__ANON__. This doesn't cause a loop, since in this case the
__ANON__ glob doesn't point to the CV. This also avoids dangling pointers
if someone does an explicit 'delete $foo::{__ANON__}'.
Note that there was already some partial protection for CvGV with
commit f1c32fec87699aee2eeb638f44135f21217d2127. This worked by
anonymising any corresponding CV when freeing a stash or stash entry.
This had two drawbacks. First it didn't fix CVs that were anonmous or that
weren't currently pointed to by the GV (e.g. after local *foo), and
second, it caused *all* CVs to get anonymised during cleanup, even the
ones that would have been deleted shortly afterwards anyway. This commit
effectively removes that former commit, while reusing a bit of the
actual anonymising code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each CV usually has a pointer, CvSTASH, back to the stash that it was
complied in. This pointer isn't reference counted, to avoid loops. Which
can leave it dangling if the stash is deleted.
There is already protection for the similar GvSTASH field in GVs: the
stash has an array of backrefs, xhv_backreferences, pointing to the GVs
whose GvSTASHes point to it, and which is used to zero all the GvSTASH
fields should the stash be deleted.
All this patch does is also add the CVs with CvSTASH to that stash's
backref list too.
|
| |
|
|
| |
Use an intermediate variable cv to avoid lots of GvCV(gv)'s
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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, <>.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The message ‘Variable "%s" is not imported’ cannot be suppressed, even
with -X (local $SIG{__WARN__}=sub{} is what I have to use):
perl -Xle '$foo;use strict; eval q/$foo/ or die "---$@---"'
Variable "$foo" is not imported at (eval 1) line 2.
---Global symbol "$foo" requires explicit package name at (eval 1) line 2.
--- at -e line 1.
This is because we have what appears to the user to be a multi-line
error message. It is in fact a warning ‘Variable...’ followed by an
error ‘Global symbol...’.
The attached patch assigns a warning category to the warning.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
It can be hard especially for those unfamiliar with the source to find
where variables like $` and $[ are set up, now they're just a ack -Q
away.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Attached is a patch that changes how the tokeniser looks up subroutines,
when they're referenced by a bareword, for prototype and const-sub
purposes. Formerly, it has looked up bareword subs directly in the
package, which is contrary to the way the generated op tree looks up
the sub, via an rv2cv op. The patch makes the tokeniser generate the
rv2cv op earlier, and dig around in that.
The motivation for this is to allow modules to hook the rv2cv op
creation, to affect the name->subroutine lookup process. Currently,
such hooking affects op execution as intended, but everything goes wrong
with a bareword ref where the tokeniser looks at some unrelated CV,
or a blank space, in the package. With the patch in place, an rv2cv
hook correctly affects the tokeniser and therefore the prototype-based
aspects of parsing.
The patch also changes ck_subr (which applies the argument context and
checking parts of prototype behaviour) to handle subs referenced by an
RV const op inside the rv2cv, where formerly it would only handle a gv
op inside the rv2cv. This is to support the most likely kind of
modified rv2cv op.
The attached patch is the resulting revised version of the bareword
sub patch. It incorporates the original patch (allowing rv2cv op
hookers to control prototype processing), the GV-downgrading addition,
and a mention in perldelta.
|
| |
|
|
|
|
|
|
|
|
|
| |
If this is defined, it will be called instead of stringification
whenever an object is used as a regexp or interpolated into a regexp.
This will fall back to stringification even without C<fallback => 1>,
for compatibility.
An overloaded 'qr' must return either a REGEXP or a ref to a REGEXP
(such as created by qr//). Any further overloading on the return value
will be ignored.
|
| | |
|
| |
|
|
|
|
|
| |
None were documented as also being in 'syntax'. Effectively, this completes the
reorganisation of commits 12bcd1a617c74d6e and 9014280dc8264580. See
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2009-10/msg00601.html and
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-03/msg00850.html
|
| |
|
|
|
| |
Replace ckWARN_d{,2,3,4}() && Perl_warner() with it, which trades reduced code
size for 1 more function call if warnings are not enabled.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
As it may be needed later when the lookup failed.
This fixes [perl #69066].
However, from now, "package ::" and "package foo::" respectively introduce
the "::" and "foo::" packages. Deciding if this is the correct thing to do
ought to be addressed separately.
|
| | |
|
| |
|
|
| |
and tweaking Perl_sv_upgrade().
|
| |
|
|
| |
The "short" names become macro wrappers, and the Perl_* versions become mathoms.
|
| |
|
|
| |
This fixes bug #68182
|
| |
|
|
|
| |
This way we'll restore most of the performance on object desctruction
lost by the previous commit
|
| |
|
|
|
|
|
|
| |
This boolean parameter indicates if the function has been called
to update the overload magic table while looking up the DESTROY
method. In this case, it's probably best to avoid croaking if
those tables could not be updated (for example due to a method
that could not be loaded.)
|
| |
|
|
| |
matching entry in perldiag (and fix it so that more of the existing ones do).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Curiously, this appears to always have been implemented slightly inefficiently.
It dates from perl 4.000, which added the functionality to make assigning to $0
set the process name. The equivalent fix for 4.000 is:
--- a/perl.c
+++ b/perl.c
@@ -738,7 +738,7 @@ FIX YOUR KERNEL, PUT A C WRAPPER AROUND THIS SCRIPT, OR USE -u AND UNDUMP!\n");
(void)hadd(sigstab);
}
- magicalize("!#?^~=-%.+&*()<>,\\/[|`':\004\t\020\024\027\006");
+ magicalize("!#?^~=-%.+&*()<>,\\/[|`':0\004\t\020\024\027\006");
userinit(); /* in case linked C routines want magical variables */
amperstab = stabent("&",allstabs);
@@ -828,7 +828,6 @@ FIX YOUR KERNEL, PUT A C WRAPPER AROUND THIS SCRIPT, OR USE -u AND UNDUMP!\n");
#endif
if (tmpstab = stabent("0",allstabs)) {
str_set(stab_val(tmpstab),origfilename);
- magicname("0", Nullch, 0);
}
if (tmpstab = stabent("\030",allstabs))
str_set(stab_val(tmpstab),origargv[0]);
|
| | |
|
| |
|
|
|
| |
Explicitly zero the memory for PL_psig_ptr, PL_psig_name and PL_psig_pend if we
didn't need to allocate it this time round.
|
| | |
|
| | |
|
| |
|
|
| |
allowed to access the corresponding string buffer byte
|
| |
|
|
| |
In amagic_call(), the 'method' arg comes the overload enum in overload.h, but is expected to match the bit set from %overloading::numbers::names. It values wrongly start at 1, differing by 1 from the enum indexes. This didn't appear in the tests because 'method' was reduced modulo 7 instead of 8.
|
| | |
|
| |
|
|
| |
Plus a comment by Nicholas
|
| | |
|
