summaryrefslogtreecommitdiff
path: root/pad.c
Commit message (Collapse)AuthorAgeFilesLines
* [perl #98092] Fix unreferenced scalar warnings in clone.tFather Chrysostomos2011-09-011-14/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit da6b625f78 triggered an unrelated bug, by rearranging things in memory so that the conditions were right: If @DB::args has been populated, and then the items in it have been freed, they can end up being reused for any SV-ish things allocated thereafter, even lexical pads. Each CV (subroutine) has a list of pads, called the padlist, which is the same structure as a Perl array (an AV) underneath. The padlist’s memory management is done in pad.c, as there are other things that have to be done when its elements (the pads themselves) are freed. So, to prevent av.c from trying to free those elements, the padlist is not marked REAL; i.e., it’s marked as not having its elements refer- ence-counted, even though they are: it’s just not handled in av.c The ‘Attempt to free unreferenced scalar’ warnings emitted by threads::shared’s clone.t occurred when padlists and pads ended up using freed SVs that were still in @DB::args. When a new thread was created, the pads in @DB::args ended up getting cloned when @DB::args was cloned; hence they were treated as non-reference-counting arrays, and the pads inside them were cloned with a lower reference count than they ought to have had (sv_dup was called, instead of sv_dup_inc). The pad-duplication code (pad_dup), like the regular SV-duplication code, checks first to see if a padlist has been cloned already, before actually doing it. There was also a problem with pad_dup not incre- menting the reference count of an already-cloned padlist. So this commit fixes the pad_dup reference-counting bug and also leaves AvREAL on for padlists, until the very last moment when they are freed (in pad_free) with SvREFCNT_dec.
* Add find_rundefsv2 functionFather Chrysostomos2011-08-241-0/+18
| | | | | | | | | | Subs in the CORE package with a (_) prototype will use this. This accepts a CV and a sequence number, so that one can use it to find the $_ in the caller’s scope. It only uses the topmost call of a subroutine that is being called recur- sively, so it’s not really a general-purpose function. But it suffices for &CORE::abs and friends.
* [perl #71154] undef &$coderef consistencyFather Chrysostomos2011-08-241-2/+3
| | | | | | | | | | | | | | $ perl -le' undef &{$x=sub{}}; $x->()' Not a CODE reference at -e line 1. undeffing an anonymous subroutine used to turn the ANON flag off, causing it to bypass the condition apparently written for this situa- tion in pp_entersub. This commit stops cv_undef from turning off that flag, so now we get: $ ./perl -le' undef &{$x=sub{}}; $x->()' Undefined subroutine called at -e line 1.
* [perl #96126] Allocate CvFILE more simplyFather Chrysostomos2011-08-171-10/+3
| | | | | | | | | | | | | | | | | | | See the thread starting at: http://www.nntp.perl.org/group/perl.perl5.porters/2011/07/msg175161.html Instead of assuming that only Perl subs have mallocked CvFILEs and only under threads, resulting in various hackery to borrow parts of the SvPVX buffer where that assumption proves wrong, we can simply add another flag (DYNFILE) to indicate whether CvFILE is mallocked, instead of trying to use the ISXSUB flag for two purposes. This simplifies the code greatly, eliminating bug #96126 in the pro- cess (which had to do with sv_dup not knowing about the hackery that this commit removes). I removed that comment from cv_ckproto_len about CONSTSUBs doubling up the buffer field, as it is no longer relevant. But I still left the code as it is, since it’s better to do an explicit length check.
* use the correct type for a format field width parameterTony Cook2011-07-241-1/+1
| | | | This was warning in DEBUGGING builds
* Change sv_eq_pvn_flags()'s parameter pvlen from I32 to STRLEN.Nicholas Clark2011-07-151-2/+2
| | | | Change its return type to bool from I32, as it only returns truth or falsehood.
* Make prototypes and declarations for Perl_pad_add_name_{pv,pvn,sv} agree.Nicholas Clark2011-07-141-1/+1
| | | | | | cc76b5cc1552a605 added all 3 functions to the API, but declared prototypes with const U32 flags, whilst the definitions had that parameter non-const. Some compilers issue warnings about this inconsistency.
* Fix perlintern links; regen known pod issuesFather Chrysostomos2011-07-121-2/+4
|
* Cleaned up warning messages in pad.c, plus related tests.Brian Fraser2011-07-121-9/+16
|
* Cleanup of pad fetching and storing. This version normalizes the data on ↵Brian Fraser2011-07-121-3/+30
| | | | both sides, which isn't required, but may be more efficient than leaving it to the comparison function.
* Added sv_eq_pvn_flags to pad.c, which will be used by later commits.Brian Fraser2011-07-121-0/+41
|
* pad.c: flags checking for the UTF8 flag when necessaryBrian Fraser2011-07-121-3/+9
|
* Added a flags parameter to pad_findlex.Brian Fraser2011-07-121-8/+8
|
* APIify pad functionsZefram2011-07-121-154/+290
| | | | | | | Move several pad functions into the core API. Document the pad functions more consistently for perlapi. Fix the interface issues around delimitation of lexical variable names, providing _pvn, _pvs, _pv, and _sv forms of pad_add_name and pad_findmy.
* Test that SvFLAGS() & SVpad_NAME is SVpad_NAME, not just non-zero.Nicholas Clark2011-06-111-2/+1
| | | | | In Perl_find_rundefsv() and PAD_COMPNAME_FLAGS_isOUR(), replace longhand flags test with SvPAD_OUR().
* fix typo in new pad.c commentDavid Mitchell2011-02-061-3/+3
|
* allow wrap-around of PL_cop_seqmaxDavid Mitchell2011-02-061-6/+37
| | | | | | | | | | | | 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].
* make 0 not a special value for COP_SEQ_RANGE_HIGHDavid Mitchell2011-02-061-9/+22
| | | | | | | 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.
* rename PAD_MAX to PERL_PADSEQ_INTRODavid Mitchell2011-02-061-11/+14
| | | | | | | | 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.
* many string evals cause eventual scope issuesDavid Mitchell2011-02-061-2/+2
| | | | | | | | | | [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.
* Fix typos (spelling errors) in Perl sources.Peter J. Acklam) (via RT2011-01-071-3/+3
| | | | | | | | | # 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>
* [perl #19135] string eval turns off readonlyness on lexicalsFather Chrysostomos2010-12-081-5/+0
| | | | | | | | | | | | | | | | | | | | | 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.
* No need to clone pad name 0, as it's never used.Nicholas Clark2010-11-231-1/+1
| | | | | Pad entry 0 is for @_, but no name is recorded for it, so the name slot is always &PL_sv_undef.
* In Perl_cv_undef(), only check potential pads against PL_comppadNicholas Clark2010-11-171-4/+8
| | | | | | 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.
* In S_pad_check_dup(), no need to check the 0th name entry.Nicholas Clark2010-11-171-2/+3
| | | | | The 0th entry in a pad is for @_, and the name corresponding to it is NULL, so save a check.
* Inline Perl_pad_undef() into its only caller, Perl_cv_undef().Nicholas Clark2010-11-161-101/+84
| | | | | Perl_pad_undef was never in the API, and has no users (elsewhere in core, on CPAN, or anywhere else visible to Google codesearch).
* Move Perl_cv_undef() from op.c to pad.cNicholas Clark2010-11-161-0/+66
| | | | This will allow the non-API function Perl_pad_undef to be inlined into it.
* In Perl_pad_new(), allocate a 2 element array for padlist.Nicholas Clark2010-11-161-2/+12
| | | | | | | | | 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.
* In Perl_pad_new(), avoid calling av_fetch() for something we already know.Nicholas Clark2010-11-161-3/+3
| | | | | | | | | 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.
* Eliminate PL_dirtyFlorian Ragwitz2010-11-141-1/+1
| | | | | It now only exists as a compatibility macro for extensions that want to introspect it.
* add CvSTASH_set() macro and make CvSTASH() rvalue onlyZefram2010-10-251-3/+1
| | | | | | 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().
* fix a couple of -Dmad compiler warningsDavid Mitchell2010-09-121-1/+2
|
* add CvGV_set() macro and make CvGV() rvalue onlyDavid Mitchell2010-07-181-1/+1
| | | | | | 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()
* change when to make CvGV refcountedDavid Mitchell2010-07-181-1/+1
| | | | | | | | | | | 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.
* protect CvGV weakref with backrefDavid Mitchell2010-07-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* protect CvSTASH weakref with backrefsDavid Mitchell2010-07-141-0/+2
| | | | | | | | | | | | | | 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.
* Make pp_reverse fetch the lexical $_ from the correct padVincent Pit2010-06-031-0/+22
| | | | | | This is achieved by introducing a new find_rundefsv() function in pad.c This fixes [perl #75436].
* In Perl_pad_add_name(), use sv_upgrade() directly rather than new[AH]V().Nicholas Clark2010-05-311-5/+5
| | | | | | | | | | 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.
* Only allocate entries for @_ when the subroutine is first called.Nicholas Clark2010-05-301-3/+0
| | | | | | | | | | | | | | 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.
* Set PADSTALE on all lexicals at the end of sub creation.Nicholas Clark2010-05-241-2/+25
| | | | | | | | | 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.
* Don't clone the contents of lexicals in pads.Nicholas Clark2010-05-241-1/+45
| | | | | | | | 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. :-(
* In Perl_pad_tidy(), merge the SvPADTMP_on() loops for padtidy_SUB and _FORMAT.Nicholas Clark2010-05-241-10/+1
|
* In Perl_padlist_dup() don't duplicate @_ or pads caused by recursion.Nicholas Clark2010-05-241-5/+56
| | | | | CvDEPTH() is 0 in a new thread, so duplicating pads beyond the always-present first level is a waste of effort and memory.
* Convert PAD_DUP to a function Perl_padlist_dup().Nicholas Clark2010-05-241-0/+25
| | | | assert() that pads are never AvREAL().
* In comments, correct two instances of SVf_PADSTALE to SVs_PADSTALE.Nicholas Clark2010-03-081-2/+2
|
* Missing static storage class for some new static functionsRafael Garcia-Suarez2009-11-201-1/+1
|
* Make the style of pad_add_name's flags consistent with pad_new's and pad_tidy's.Nicholas Clark2009-11-151-7/+7
|
* Change S_pad_check_dup()'s arguments from char*/STRLEN to SV *.Nicholas Clark2009-11-151-15/+8
| | | | Within the function, use sv_eq() rather than strcmp().
* Convert pad_check_dup() to static linkage, and call it from Perl_pad_add_name().Nicholas Clark2009-11-151-7/+9
| | | | | Provide a flag option to Perl_pad_add_name(), pad_add_NO_DUP_CHECK, to supress the call.
* Refactor common code paths from Perl_pad_add_name() into S_pad_add_name_sv().Nicholas Clark2009-11-151-56/+69
| | | | | | 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.