summaryrefslogtreecommitdiff
path: root/pad.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Close over stale vars in active subsFather Chrysostomos2012-08-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | \$x and sub { $x }->() should never produce different values. But this used to be possible because sub cloning (which happens with sub{...}) was written to avoid closing over variables that are not active. Not closing over inactive variables makes sense in cases like this (because the variable doesn’t really exist yet): sub { my $x; sub foo { $x } } foo; but the logic breaks down in cases like this (which was printing 3 only on the first print): sub foo { my $x; sub bar { $x = 3; print $x, "\n"; sub { print $x, "\n" }->() } } bar(); If bar can see a scalar named $x (even if it is questionable), sub { $x }->() should jolly well see the same scalar as the immedi- ately enclosing sub. The only case where a run-time cloning of a CV should refuse to close over the same scalar that the outer sub sees is when the outer sub is not running. That only happens with formats: sub f { my $x; format = @ $x . } write STDOUT; As of this commit, it does only happen with formats. The actual cases of subs refusing to close over stale variables in active parents have changed twice since 5.10.0. See the comments in the tests.
* Make undef &foo remove call checkersFather Chrysostomos2012-07-291-0/+1
| | | | | | | | | The fact that the call checker is stored in magic is an implementation detail. cv_undef does not free magic, so the call checker lives on. If we were to move the parameter prototype into magic internally, we would not want undef to stop clearing it. To me, the current situa- tion with call checkers is similar.
* pad.c: document cv_forget_slabFather Chrysostomos2012-07-291-0/+12
|
* Eliminate PL_OP_SLAB_ALLOCFather Chrysostomos2012-07-121-16/+10
| | | | | | | | | | | | This commit eliminates the old slab allocator. It had bugs in it, in that ops would not be cleaned up properly after syntax errors. So why not fix it? Well, the new slab allocator *is* the old one fixed. Now that this is gone, we don’t have to worry as much about ops leak- ing when errors occur, because it won’t happen any more. Recent commits eliminated the only reason to hang on to it: PERL_DEBUG_READONLY_OPS required it.
* PERL_DEBUG_READONLY_OPS with the new allocatorFather Chrysostomos2012-07-121-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | I want to eliminate the old slab allocator (PL_OP_SLAB_ALLOC), but this useful debugging tool needs to be rewritten for the new one first. This is slightly better than under PL_OP_SLAB_ALLOC, in that CVs cre- ated after the main CV starts running will get read-only ops, too. It is when a CV finishes compiling and relinquishes ownership of the slab that the slab is made read-only, because at that point it should not be used again for allocation. BEGIN blocks are exempt, as they are processed before the Slab_to_ro call in newATTRSUB. The Slab_to_ro call must come at the very end, after LEAVE_SCOPE, because otherwise the ops freed via the stack (the SAVEFREEOP calls near the top of newATTRSUB) will make the slab writa- ble again. At that point, the BEGIN block has already been run and its slab freed. Maybe slabs belonging to BEGIN blocks can be made read-only later. Under PERL_DEBUG_READONLY_OPS, op slabs have two extra fields to record the size and readonliness of each slab. (Only the first slab in a CV’s slab chain uses the readonly flag, since it is conceptually simpler to treat them all as one unit.) Without recording this infor- mation manually, things become unbearably slow, the tests taking hours and hours instead of minutes.
* pad.c: Improve intro_my docsFather Chrysostomos2012-07-021-1/+3
|
* Cloning a format whose outside has been undefinedFather Chrysostomos2012-06-301-5/+7
| | | | | | | | | | | | | | | | | | | This has crashed ever since 71f882da8, because the format tries to close over a pad that does not exist: sub x { {my ($a,$b,$c,$d,$e,$f,$g,$h,$i,$j,$k,$l,$m,$n,$o,$p,$q,$r,$s,$t,$u)} my $z; format = @<<< $z . } undef &x; write; This commit adds checks for nonexistent pads, producing the ‘Variable is not available’ warning in cases like this.
* pad.c: Update commentsFather Chrysostomos2012-06-291-3/+5
|
* Make formats close over the right closureFather Chrysostomos2012-06-291-3/+4
| | | | | | | | | | | | | | | | | This was brought up in ticket #113812. Formats that are nested inside closures only work if invoked from directly inside that closure. Calling the format from an inner sub call won’t work. Commit af41786fe57 stopped it from crashing, making it work as well as 5.8, in that closed-over variables would be undefined, being unavailable. This commit adds a variation of the find_runcv function that can check whether CvROOT matches an argument passed in. So we look not for the current sub, but for the topmost sub on the call stack that is a clone of the closure prototype that the format’s CvOUTSIDE field points to.
* [perl #113812] Always use find_runcv when cloning a subFather Chrysostomos2012-06-291-4/+8
| | | | | | | | | | | | A closure prototype’s CvOUTSIDE pointer might have been modified if its containing sub is freed first. When a sub is cloned, the enclos- ing sub is always the currently-running sub (not so for formats). So this commit makes subs always use find_runcv, the way they did before 71f882da828. So the closure logic which was needed for formats is now moved into an else branch that is used only for them.
* CV-based slab allocation for opsFather Chrysostomos2012-06-291-1/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This addresses bugs #111462 and #112312 and part of #107000. When a longjmp occurs during lexing, parsing or compilation, any ops in C autos that are not referenced anywhere are leaked. This commit introduces op slabs that are attached to the currently- compiling CV. New ops are allocated on the slab. When an error occurs and the CV is freed, any ops remaining are freed. This is based on Nick Ing-Simmons’ old experimental op slab implemen- tation, but it had to be rewritten to work this way. The old slab allocator has a pointer before each op that points to a reference count stored at the beginning of the slab. Freed ops are never reused. When the last op on a slab is freed, the slab itself is freed. When a slab fills up, a new one is created. To allow iteration through the slab to free everything, I had to have two pointers; one points to the next item (op slot); the other points to the slab, for accessing the reference count. Ops come in different sizes, so adding sizeof(OP) to a pointer won’t work. The old slab allocator puts the ops at the end of the slab first, the idea being that the leaves are allocated first, so the order will be cache-friendly as a result. I have preserved that order for a dif- ferent reason: We don’t need to store the size of the slab (slabs vary in size; see below) if we can simply follow pointers to find the last op. I tried eliminating reference counts altogether, by having all ops implicitly attached to PL_compcv when allocated and freed when the CV is freed. That also allowed op_free to skip FreeOp altogether, free- ing ops faster. But that doesn’t work in those cases where ops need to survive beyond their CVs; e.g., re-evals. The CV also has to have a reference count on the slab. Sometimes the first op created is immediately freed. If the reference count of the slab reaches 0, then it will be freed with the CV still point- ing to it. CVs use the new CVf_SLABBED flag to indicate that the CV has a refer- ence count on the slab. When this flag is set, the slab is accessible via CvSTART when CvROOT is not set, or by subtracting two pointers (2*sizeof(I32 *)) from CvROOT when it is set. I decided to sneak the slab into CvSTART during compilation, because enlarging the xpvcv struct by another pointer would make all CVs larger, even though this patch only benefits few (programs using string eval). When the CVf_SLABBED flag is set, the CV takes responsibility for freeing the slab. If CvROOT is not set when the CV is freed or undeffed, it is assumed that a compilation error has occurred, so the op slab is traversed and all the ops are freed. Under normal circumstances, the CV forgets about its slab (decrement- ing the reference count) when the root is attached. So the slab ref- erence counting that happens when ops are freed takes care of free- ing the slab. In some cases, the CV is told to forget about the slab (cv_forget_slab) precisely so that the ops can survive after the CV is done away with. Forgetting the slab when the root is attached is not strictly neces- sary, but avoids potential problems with CvROOT being written over. There is code all over the place, both in core and on CPAN, that does things with CvROOT, so forgetting the slab makes things more robust and avoids potential problems. Since the CV takes ownership of its slab when flagged, that flag is never copied when a CV is cloned, as one CV could free a slab that another CV still points to, since forced freeing of ops ignores the reference count (but asserts that it looks right). To avoid slab fragmentation, freed ops are marked as freed and attached to the slab’s freed chain (an idea stolen from DBM::Deep). Those freed ops are reused when possible. I did consider not reusing freed ops, but realised that would result in significantly higher mem- ory using for programs with large ‘if (DEBUG) {...}’ blocks. SAVEFREEOP was slightly problematic. Sometimes it can cause an op to be freed after its CV. If the CV has forcibly freed the ops on its slab and the slab itself, then we will be fiddling with a freed slab. Making SAVEFREEOP a no-op won’t help, as sometimes an op can be savefreed when there is no compilation error, so the op would never be freed. It holds a reference count on the slab, so the whole slab would leak. So SAVEFREEOP now sets a special flag on the op (->op_savefree). The forced freeing of ops after a compilation error won’t free any ops thus marked. Since many pieces of code create tiny subroutines consisting of only a few ops, and since a huge slab would be quite a bit of baggage for those to carry around, the first slab is always very small. To avoid allocating too many slabs for a single CV, each subsequent slab is twice the size of the previous. Smartmatch expects to be able to allocate an op at run time, run it, and then throw it away. For that to work the op is simply mallocked when PL_compcv has’t been set up. So all slab-allocated ops are marked as such (->op_slabbed), to distinguish them from mallocked ops. All of this is kept under lock and key via #ifdef PERL_CORE, as it should be completely transparent. If it isn’t transparent, I would consider that a bug. I have left the old slab allocator (PL_OP_SLAB_ALLOC) in place, as it is used by PERL_DEBUG_READONLY_OPS, which I am not about to rewrite. :-) Concerning the change from A to X for slab allocation functions: Many times in the past, A has been used for functions that were not intended to be public but were used for public macros. Since PL_OP_SLAB_ALLOC is rarely used, it didn’t make sense for Perl_Slab_* to be API functions, since they were rarely actually available. To avoid propagating this mistake further, they are now X.
* Formats in closures called outside closures → crashFather Chrysostomos2012-06-281-3/+7
| | | | | | | | | | | | | | | | | | | If a format closing over lexical variables is defined inside a clo- sure, it must only be called directly inside that closure, not from any other eval, sub, or format. Calling it from anywhere else started causing a crash in 5.10.0, because the format would try to close over variables in the currently- running sub, using padoffsets intended for a completely unrelated pad. This commit stops it from crashing by checking whether the currently- running sub is a clone of the format’s outer sub (a closure proto- type). If it is not, the outer closure prototype is used, resulting in ‘Variable is not available’ warnings. This makes things work as well as they did in 5.8. Ideally, we should search the call stack for the topmost clone of the format’s outer sub; but I’m saving that for another commit.
* Don’t let formats outlive their outer subsFather Chrysostomos2012-06-281-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This began crashing in 5.11.3: sub foo { sub bar { my ($a,$b,$c,$d,$e,$f,$g,$h,$i,$j,$k,$l,$m,$n,$o,$p,$q,$r,$s,$x); format = @|||||| $x . } } undef *bar; write; (On some systems, you need more alphabet soup to make it crash.) This commit (just the perly.y part shown) caused it to crash: commit 421f30ed1e95009450bdc7905bf3433ee806ea4f Author: Zefram <zefram@fysh.org> Date: Tue Dec 15 11:48:31 2009 +0100 [perl #22977] Bug in format/write diff --git a/perly.y b/perly.y index 18e5875..a61a6b3 100644 --- a/perly.y +++ b/perly.y @@ -511,7 +511,9 @@ peg : PEG ; format : FORMAT startformsub formname block - { SvREFCNT_inc_simple_void(PL_compcv); + { + CV *fmtcv = PL_compcv; + SvREFCNT_inc_simple_void(PL_compcv); #ifdef MAD $$ = newFORM($2, $3, $4); prepend_madprops($1->tk_mad, $$, 'F'); @@ -521,6 +523,10 @@ format : FORMAT startformsub formname block newFORM($2, $3, $4); $$ = (OP*)NULL; #endif + if (CvOUTSIDE(fmtcv) && !CvUNIQUE(CvOUTSIDE(fmtcv))) { + SvREFCNT_inc_simple_void(fmtcv); + pad_add_anon((SV*)fmtcv, OP_NULL); + } } ; Unfortunately, adding the format to the pad like that (to allow pad_fixup_inner_anons to fix up formats as well as subs) is proble- matic. It causes the format’s CvOUTSIDE to be weak. Since the for- mat does not hold a reference count on its outer sub, that sub can be freed before the format. When that happens, regular subs are fixed up by having CvOUTSIDE change to point to the grandparent. If you do that for formats, you run into a problem: Formats can be cloned even when the outer sub is not running. Formats are cloned whenever invoked *by name* via write. If CvOUTSIDE points to a different sub, then closing over the scalars in specific pad offsets in that sub can result in reading past the end of the pad. If you don’t read past the end of the pad, you are still making variables close over unrelated variables, so the inner $x could close over an outer @y, etc. Subrou- tines don’t have that problem, as they can only be cloned when they have an outer sub. (Even though the outer sub’s prototype, if it is a closure, might have been freed, the outer sub itself is still running and referenced by the context stack.) This commit changes the direction of the weak reference between an outer sub’s pad and an inner format, fixing the crash. To do so, it has to store, not the format itself, but a weak RV point- ing to the format, in the outer sub’s pad.
* [perl #113812] Handle null CvOUTSIDE in cv_cloneFather Chrysostomos2012-06-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit a0d2bbd stopped closures from hanging on to their enclosing subs. This means that the outer sub can be freed before the closure. Since it is only the outer sub that references the closure prototype (in a '&' entry in its pad), when the outer sub is freed the closure proto- type goes with it. Now if that closure itself contains a closure (more precisely, a closure prototype in its pad, referenced by an anoncode op), that inner closure prototype’s CvOUTSIDE points to the first closure prototype. When that first closure prototype is freed the innermost closure prototype has its CvOUTSIDE set to whatever the outermost sub’s CvOUTSIDE was set to, which could be null if it is in its own file. So when the first closure is called, it passes to cv_clone a closure prototype with no CvOUTSIDE. cv_clone used to crash if CvOUTSIDE was null. Example: $ cat foo.pl # the main CV of the file is the outer sub in this case my $x $first_closure = sub { $inner_closure = sub { $x } } $ perl -e 'require "./foo.pl"; $first_closure->()' Bus error This commit makes it use find_runcv when CvOUTSIDE is null.
* [perl #89544] Non-eval closures don’t need CvOUTSIDEFather Chrysostomos2012-06-201-1/+3
| | | | | | | | | | A closure doesn’t need an outside pointer at run time, unless it has a string eval in it. CvOUTSIDE is only used at compilation time to look up variables by name. Since CvOUTSIDE is reference-counted, a closure can unnecessarily hang on to variables it is not using (see the test in the diff). So stop setting it when cloning a closure, unless it is needed for eval.
* eliminate sv_compile_2op, sv_compile_2op_is_brokenDavid Mitchell2012-06-131-2/+1
| | | | | | | | | These two functions, which have been a pimple on the face of perl for far too long, are no longer needed, now that regex code blocks are compiled in a sensible manner. This also allows S_doeval() to be simplified, now that it is no longer called from sv_compile_2op_is_broken().
* pad.c: Remove obsolete commentFather Chrysostomos2012-06-041-5/+0
| | | | We now store the UTF8-ness in the pad, as of 5.15.4 or so.
* update the editor hints for spaces, not tabsRicardo Signes2012-05-291-2/+2
| | | | | This updates the editor hints in our files for Emacs and vim to request that tabs be inserted as spaces.
* Copy call checker when cloning closure prototypeFather Chrysostomos2012-05-211-0/+2
| | | | | Otherwise cv_set_call_checker has no effect inside an attribute han- dler for a closure.
* delay allocating trans table until neededZefram2012-02-251-2/+3
| | | | | | | | | | | | | | | | | | | Previously, a table was being allocated for OP_TRANS(|R), in a PVOP arrangement, as soon as the op was built. However, it wasn't used immediately, and for UTF8-flagged ops it would be thrown away, replaced by an SV-based translation table in a SVOP or PADOP arrangement. This mutation of the op structure occurred in pmtrans(), some time after original op building. If an error occurred before pmtrans(), requiring the op to be freed, op_clear() would be misled by the UTF8 flags into treating the PV as an SV or pad index, causing crashes in the latter case [perl #102858]. op_clear() was implicitly assuming that pmtrans() had been performed, due to lacking any explicit indication of the op's state of construction. Now, the PV table is allocated by pmtrans(), when it's actually going to populate it. The PV doesn't get allocated at all for UTF8-flagged ops. Prior to pmtrans(), the op_pv/op_sv/op_padix field is all bits zero, so there's no problem with freeing the op.
* Provide as much diagnostic information as possible in "panic: ..." messages.Nicholas Clark2012-01-161-4/+8
| | | | | | | | | | | | | | | The convention is that when the interpreter dies with an internal error, the message starts "panic: ". Historically, many panic messages had been terse fixed strings, which means that the out-of-range values that triggered the panic are lost. Now we try to report these values, as such panics may not be repeatable, and the original error message may be the only diagnostic we get when we try to find the cause. We can't report diagnostics when the panic message is generated by something other than croak(), as we don't have *printf-style format strings. Don't attempt to report values in panics related to *printf buffer overflows, as attempting to format the values to strings may repeat or compound the original error.
* Correct comment in pad.cFather Chrysostomos2011-10-151-1/+1
| | | | It said exactly the opposite of what was meant.
* Fix up pad_check_dup entry in perlinternFather Chrysostomos2011-10-091-4/+6
| | | | | | | | | | | | | | | | | | | | | | | When the pad API was added, the special m|pad_check_dup|SV *name|U32 flags|const HV *ourstash sequence was added to pad.c, but that is unnecessary as it is listed in embed.fnc. Also it is not correct, as the name of the function is in the return value field. So this restore it back to the simple ‘=for apidoc pad_check_dup’. The description of the function was in plain text like this: Check for duplicate declarations: report any of: * a my in the current scope with the same name; * an our (anywhere in the pad) with the same name and the same stash as C<ourstash> C<is_our> indicates that the name to check is an 'our' declaration which gets rewrapped in rendered pod. So this patch changes it to use a verbatim block (as autodoc.pl doesn’t seem to like pod lists).
* make SVs_PADTMP and SVs_PADSTALE share a bitDavid Mitchell2011-10-071-1/+1
| | | | | | | | | | | SVs_PADSTALE is only meaningful with SVs_PADMY, while SVs_PADTMP is only meaningful with !SVs_PADMY, so let them share the same flag bit. Note that this doesn't yet free a bit in SvFLAGS, as the two bits are also used for SVpad_STATE, SVpad_TYPED. (This is is follow-on to 62bb6514085e5eddc42b4fdaf3713ccdb7f1da85.)
* [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).
View Lorry Controller Status