| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
After a large number of evals, PL_cop_seqmax (a U32) will wrap around
again to zero. Make the code handle this case by:
1) When incrementing PL_cop_seqmax, never allow its value to become
equal to PERL_PADSEQ_INTRO;
2) When testing for COP_SEQ_RANGE_LOW < seq <= COP_SEQ_RANGE_HIGH,
allow for the fact that _HIGH may be lower than _LOW.
This is a final fix for [perl #83364].
|
|
|
|
|
|
|
| |
Some of the code in pad.c tests COP_SEQ_RANGE_HIGH for the special value 0.
By instead testing COP_SEQ_RANGE_LOW for the special value PERL_PADSEQ_INTRO
(which it turns out is functioanlly equivalent), we can eliminate one of
the special values that PL_cop_seqmax mustn't be set to.
|
|
|
|
|
|
|
|
| |
and increase its scope to all the perl core rather than just pad.c.
The scope needs to increase because we'll need to use it in op.c shortly,
and the rename is because it's about to lose any significance as a
numerical value, and just become a magic number to be tested for equality.
|
|
|
|
|
|
|
|
|
|
| |
[perl #83364]. PL_cop_seqmax is U32 but PAD_MAX was defined as
I32_MAX. Once PL_cop_seqmax got above 2 billion it would start to appear
spuriosuly as if PL_cop_seqmax > PAD_MAX, so the scope of lexical vars in
evals etc went awry.
Also replaces a use of ~0 with PAD_MAX, which shouldn't change anything,
but is just tidier.
|
|
|
|
|
|
|
|
|
| |
# New Ticket Created by (Peter J. Acklam)
# Please include the string: [perl #81904]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=81904 >
Signed-off-by: Abigail <abigail@abigail.be>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don’t turn off readonliness on lexicals when freeing pad entries.
The readonliness is (prior to this commit) turned off explicitly in
pad_free under ithreads. See also bug #19022, which resulted from the
same change. There is some discussion there, too, but nobody seemed to
know exactly why the readonliness needed to be turned off.
Change 4761/2aa1bed, from January of 2000, added that SvREADONLY_off.
It is supposed to make sure that pad entries that were constants will
not be constants the next time they are used.
Dave Mitchell writes:
> I think...[this]...fix is correct (just removing the SvREADONLY_off).
> The issue it was trying to fix appears to have been properly fixed
> later by 3b1c21fabed159100271bd60bac3f870f5ac16af, which is why it's
> safe to remove it.
So this commit just deletes that code.
|
|
|
|
|
| |
Pad entry 0 is for @_, but no name is recorded for it, so the name slot is
always &PL_sv_undef.
|
|
|
|
|
|
| |
Don't even try checking the address of the pad name AV against PL_comppad, and
don't try checking the address of pad AVs against PL_comppad_name. Neither will
ever match.
|
|
|
|
|
| |
The 0th entry in a pad is for @_, and the name corresponding to it is NULL,
so save a check.
|
|
|
|
|
| |
Perl_pad_undef was never in the API, and has no users (elsewhere in core,
on CPAN, or anywhere else visible to Google codesearch).
|
|
|
|
| |
This will allow the non-API function Perl_pad_undef to be inlined into it.
|
|
|
|
|
|
|
|
|
| |
Most subroutines never recurse, hence only need 2 entries in the padlist
array - names, and depth=1. The default for av_store() is to allocate 0..3,
and even an explicit call to av_extend() with <3 will be rounded up, so we
inline the allocation of the array here.
Running ./installman allocates 7K less with this change.
|
|
|
|
|
|
|
|
|
| |
We've just stored padname and pad as the first two elements in padlist - so
calling av_fetch() is makework.
The code was the way it was because dd2155a49b710f23 moved the two halves from
disjoint locations into the same function adjacent to each other, but didn't
spot this subsequent optimisation.
|
|
|
|
|
| |
It now only exists as a compatibility macro for extensions that want to
introspect it.
|
|
|
|
|
|
| |
Now that CvSTASH requires backreference bookkeeping, stop people from
directly assigning to it (by using CvSTASH() as an lvalue), and instead
force them to use CvSTASH_set().
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
This is achieved by introducing a new find_rundefsv() function in pad.c
This fixes [perl #75436].
|
|
|
|
|
|
|
|
|
|
| |
As newAV() and newHV() are now merely wrappers around sv_upgrade(), and the
existing SV is always brand new and of type SVt_NULL, call them on it, rather
than disposing of it as a side effect of storing a(nother new) SV.
Also, no need to set SvPADMY() again, as it is already set.
Resolves RT #73092.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, @_ was allocated for every subroutine at compile time, with a
default sized AV, hence space for 4 entries. We don't actually need to
allocate the space for entries, as there is already a check at call time as to
whether @_ is long enough.
valgrind suggests that this saves allocating 23K (on a 64 bit platform) when
running pod2man on perlfunc.pod. As well as the absolute saving, there is also
benefit in deferring allocation for subroutines actually called - for a program
which forks, @_ is less likely to be in pages shared COW with the parent.
Resolves RT #72416.
|
|
|
|
|
|
|
|
|
| |
The PADSTALEness of lexicals between the 0th and 1st call to a subroutine is now
consistent with the state between the nth and (n + 1)th call.
This permits a work around in Perl_padlist_dup() to avoid leaking active pad
data into a new thread, whilst still correctly bodging the external references
needed by the current ?{} implementation. Fix that, and this can be removed.
|
|
|
|
|
|
|
|
| |
This stops the values of lexicals in active stack frames in the parent leaking
into the lexicals in the child thread.
With an exception for lexicals with a reference count of > 1, to cope with the
implementation of ?{{ ... }} blocks in regexps. :-(
|
| |
|
|
|
|
|
| |
CvDEPTH() is 0 in a new thread, so duplicating pads beyond the always-present
first level is a waste of effort and memory.
|
|
|
|
| |
assert() that pads are never AvREAL().
|
| |
|
| |
|
| |
|
|
|
|
| |
Within the function, use sv_eq() rather than strcmp().
|
|
|
|
|
| |
Provide a flag option to Perl_pad_add_name(), pad_add_NO_DUP_CHECK, to supress
the call.
|
|
|
|
|
|
| |
The only user of the pad_add_FAKE flag was S_pad_findlex(), so move the relevant
code there from Perl_pad_add_name(), and have S_pad_findlex() call
S_pad_add_name_sv() directly. This eliminates the pad_add_FAKE flag completely.
|
|
|
|
|
|
| |
Currently only pad_add_STATE and pad_add_FAKE are used. The length is cross-
checked against strlen() on the pointer, but the intent is to re-work the entire
pad API to be UTF-8 aware, from the current situation of char * pointers only.
|
|
|
|
|
|
| |
Currently only pad_add_OUR is used. The length is cross-checked against
strlen() on the pointer, but the intent is to re-work the entire pad API to
be UTF-8 aware, from the current situation of char * pointers only.
|
|
|
|
| |
It already knows its length, and it will be UTF-8 clean in the future.
|
|
|
|
|
|
|
|
| |
API.
Currently no flags bits are used, and the length is cross-checked against
strlen() on the pointer, but the intent is to re-work the entire pad API to be
UTF-8 aware, from the current situation of char * pointers only.
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
p4raw-id: //depot/perl@34934
|
|
|
|
|
|
| |
I32. This permits some space saving rejigging of the interpreter
struct.
p4raw-id: //depot/perl@34930
|
|
|
|
|
| |
Protect the prototype of S_vdie() with #if defined (PERL_IN_UTIL_C)
p4raw-id: //depot/perl@34929
|
|
|
|
|
|
| |
Message-ID: <25940.1225611819@chthon>
Date: Sun, 02 Nov 2008 01:43:39 -0600
p4raw-id: //depot/perl@34698
|
|
|
|
|
| |
erroneous const in dump.c.
p4raw-id: //depot/perl@34675
|
|
|
| |
p4raw-id: //depot/perl@34653
|
|
|
| |
p4raw-id: //depot/perl@34650
|
|
|
| |
p4raw-id: //depot/perl@34647
|