summaryrefslogtreecommitdiff
path: root/sv.c
Commit message (Collapse)AuthorAgeFilesLines
* Comment out unused functionKarl Williamson2012-08-251-1/+1
| | | | | | In looking at \X handling, I noticed that this function which is intended for use in it, actually isn't used. This function may someday be useful, so I'm leaving the source in.
* Use FooBAR convention for new pad macrosFather Chrysostomos2012-08-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After a while, I realised that it can be confusing for PAD_ARRAY and PAD_MAX to take a pad argument, but for PAD_SV to take a number and PAD_SET_CUR a padlist. I was copying the HEK_KEY convention, which was probably a bad idea. This is what we use elsewhere: TypeMACRO ----===== AvMAX CopFILE PmopSTASH StashHANDLER OpslabREFCNT_dec Furthermore, heks are not part of the API, so what convention they use is not so important. So these: PADNAMELIST_* PADLIST_* PADNAME_* PAD_* are now: Padnamelist* Padlist* Padname* Pad*
* Stop padlists from being AVsFather Chrysostomos2012-08-211-1/+1
| | | | | | | | | | | | | | | | | | | | | In order to fix a bug, I need to add new fields to padlists. But I cannot easily do that as long as they are AVs. So I have created a new padlist struct. This not only allows me to extend the padlist struct with new members as necessary, but also saves memory, as we now have a three-pointer struct where before we had a whole SV head (3-4 pointers) + XPVAV (5 pointers). This will unfortunately break half of CPAN, but the pad API docs clearly say this: NOTE: this function is experimental and may change or be removed without notice. This would have broken B::Debug, but a patch sent upstream has already been integrated into blead with commit 9d2d23d981.
* utf8 pos cache: always keep most recent valueDavid Mitchell2012-08-211-29/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | UTF-8 strings may have magic attached that caches up to two byte position to char position (or vice versa) mappings. When a third position has been calculated (e.g. via sv_pos_b2u()), the code has to decide how to update the cache: i.e. which value to discard. Currently for each of the three possibilities, it looks at what would be the remaining two values, and calculates the RMS sum of the three distances between ^ ... cache A .. cache B ... $. Whichever permutation gives the lowest result is picked. Note that this means that the most recently calculated value may be discarded. This makes sense if the next position request will be for a random part of the string; however in reality, the next request is more likely to be for the same position, or one a bit further along. Consider the following innocuous code: $_ = "\x{100}" x 1_000_000; $p = pos while /./g; This goes quadratic, and takes 150s on my system. The fix is is to always keep the newest value, and use the RMS calculation only to decide which of the two older values to discard. With this fix, the above code takes 0.4s. The test suite takes the same time in both cases, so there's no obvious slowdown elsewhere with this change.
* Omnibus removal of register declarationsKarl Williamson2012-08-181-48/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes most register declarations in C code (and accompanying documentation) in the Perl core. Retained are those in the ext directory, Configure, and those that are associated with assembly language. See: http://stackoverflow.com/questions/314994/whats-a-good-example-of-register-variable-usage-in-c which says, in part: There is no good example of register usage when using modern compilers (read: last 10+ years) because it almost never does any good and can do some bad. When you use register, you are telling the compiler "I know how to optimize my code better than you do" which is almost never the case. One of three things can happen when you use register: The compiler ignores it, this is most likely. In this case the only harm is that you cannot take the address of the variable in the code. The compiler honors your request and as a result the code runs slower. The compiler honors your request and the code runs faster, this is the least likely scenario. Even if one compiler produces better code when you use register, there is no reason to believe another will do the same. If you have some critical code that the compiler is not optimizing well enough your best bet is probably to use assembler for that part anyway but of course do the appropriate profiling to verify the generated code is really a problem first.
* Disallow setting SvPV on formatsFather Chrysostomos2012-08-051-13/+5
| | | | | | | Setting a the PV on a format is meaningless, as of the previ- ous commit. This frees up SvCUR for other uses.
* sv.c:varname: Fix bad assertion added by c6fb3f6eFather Chrysostomos2012-08-041-1/+1
| | | | | | | | | | | | | #!perl -w my $x; format = @ "$x"; . write; __END__ Assertion failed: (!cv || SvTYPE(cv) == SVt_PVCV), function Perl_varname, file sv.c, line 13924. Abort trap
* regcomp.c: Fix multi-char fold bugKarl Williamson2012-08-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Input text to be matched under /i is placed in EXACTFish nodes. The current limit on such text is 255 bytes per node. Even if we raised that limit, it will always be finite. If the input text is longer than this, it is split across 2 or more nodes. A problem occurs when that split occurs within a potential multi-character fold. For example, if the final character that fits in a node is 'f', and the next character is 'i', it should be matchable by LATIN SMALL LIGATURE FI, but because Perl isn't structured to find multi-char folds that cross node boundaries, we will miss this it. The solution presented here isn't optimum. What we do is try to prevent all EXACTFish nodes from ending in a character that could be at the beginning or middle of a multi-char fold. That prevents the problem. But in actuality, the problem only occurs if the input text is actually a multi-char fold, which happens much less frequently. For example, we try to not end a full node with an 'f', but the problem doesn't actually occur unless the adjacent following node begins with an 'i' (or one of the other characters that 'f' participates in). That is, this patch splits when it doesn't need to. At the point of execution for this patch, we only know that the final character that fits in the node is that 'f'. The next character remains unparsed, and could be in any number of forms, a literal 'i', or a hex, octal, or named character constant, or it may need to be decoded (from 'use encoding'). So look-ahead is not really viable. So finding if a real multi-character fold is involved would have to be done later in the process, when we have full knowledge of the nodes, at the places where join_exact() is now called, and would require inserting a new node(s) in the middle of existing ones. This solution seems reasonable instead. It does not yet address named character constants (\N{}) which currently bypass the code added here.
* [perl #114368] perl -DA -e '' segfaultsFather Chrysostomos2012-08-011-0/+4
| | | | | | Iterative freeing of hashes uses the SvMAGIC field for a different purpose. So clear it before calling hv_undef_flags, which calls hv_assert, which expects any non-null value fo SvMAGIC to me magic.
* Add a USE_64_BIT_INT build option to the Windows makefiles.Steve Hay2012-08-011-2/+2
| | | | | | | | | | | | | | | | | | Rather than adding more canned configurations, we dynamically set values which differ from the standard 32-bit build options, and actually remove the canned configurations for 64-bit builds too and do likewise for them. The ~ARCHPREFIX~ games used by the outgoing .gc64 configuration needed bringing into the remaining .gc configuration to maintain support for the GCCCROSS build option. Two tweaks to sv.c were required for the USE_64_BIT_INT option to work with a VC++ build, allowing the I64 printf size specification. The GCC build worked anyway since it uses ll rather than I64. The motivation for this change came from a patch submitted by Sisyphus <sisyphus1@optusnet.com.au>: Message-ID: <6AC52DD00C96415A9E919A02F12DD05F@desktop2>
* fix a memory leak in sv_sethek(), amending 70b71ec84Fuji, Goro2012-07-311-0/+1
| | | | | | | | | | | the following code reproduced this issue on perl 5.16.0: my $o = bless {}; while (1) { for my $r([], $o) { ref $r; } }
* Oust sv_gmagical_2iv_pleaseFather Chrysostomos2012-07-281-22/+0
| | | | | | | The magic flags patch prevents this from ever being called, since the OK flags work the same way for magic variables now as they have for muggle vars, avoid these fiddly games. (It was when writing it that I realised the value of the magic flags proposal.)
* Flatten vstrings modified in placeFather Chrysostomos2012-07-271-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A substitution forces its target to a string upon successful substitu- tion, even if the substitution did nothing: $ ./perl -Ilib -le '$a = *f; $a =~ s/f/f/; print ref \$a' SCALAR Notice that $a is no longer a glob after s///. But vstrings are different: $ ./perl -Ilib -le '$a = v102; $a =~ s/f/f/; print ref \$a' VSTRING I fixed this in 5.16 (1e6bda93) for those cases where the vstring ends up with a value that doesn’t correspond to the actual string: $ ./perl -Ilib -le '$a = v102; $a =~ s/f/o/; print ref \$a' SCALAR It works through vstring set-magic, that does the check and removes the magic if it doesn’t match. I did it that way because I couldn’t think of any other way to fix bug #29070, and I didn’t realise at the time that I hadn’t fixed all the bugs. By making SvTHINKFIRST true on a vstring, we force it through sv_force_normal before any in-place string operations. We can also make sv_force_normal handle vstrings as well. This fixes all the lin- gering-vstring-magic bugs in just two lines, making the vstring set- magic (which is also slow) redundant. It also allows the special case in sv_setsv_flags to be removed. Or at least that was what I had hoped. It turns out that pp_subst, twists and turns in tortuous ways, and needs special treatment for things like this. And do_trans functions wasn’t checking SvTHINKFIRST when arguably it should have. I tweaked sv_2pv{utf8,byte} to avoid copying magic variables that do not need copying.
* Make all the SvPV*force* macros always return sv with SvPOK_only, as APIChip Salzenberg2012-07-261-0/+1
| | | | docs always claimed they did. Also update those docs to be clearer.
* Unify code that initializes constants yes, no, and undefChip Salzenberg2012-07-231-25/+33
|
* in sv_chop(), add use SvPOK_only_UTF8() to clear obsolete NIOKChip Salzenberg2012-07-201-3/+5
|
* Magic flags harmonization.Chip Salzenberg2012-07-151-294/+264
| | | | | | | | | | | | | | | | | | | | | | | | | In restore_magic(), which is called after any magic processing, all of the public OK flags have been shifted into the private OK flags. Thus the lack of an appropriate public OK flags was used to trigger both get magic and required conversions. This scheme did not cover ROK, however, so all properly written code had to make sure mg_get was called the right number of times anyway. Meanwhile the private OK flags gained a second purpose of marking converted but non-authoritative values (e.g. the IV conversion of an NV), and the inadequate flag shift mechanic broke this in some cases. This patch removes the shift mechanic for magic flags, thus exposing (and fixing) some improper usage of magic SVs in which mg_get() was not called correctly. It also has the side effect of making magic get functions specifically set their SVs to undef if that is desired, as the new behavior of empty get functions is to leave the value unchanged. This is a feature, as now get magic that does not modify its value, e.g. tainting, does not have to be special cased. The changes to cpan/ here are only temporary, for development only, to keep blead working until upstream applies them (or something like them). Thanks to Rik and Father C for review input.
* Fix *ISA = *glob_without_arrayFather Chrysostomos2012-07-121-2/+3
| | | | | | | | | | I broke this in 5.14 with commit 6624142a. In trying to make *ISA = *Other::ISA work, I added logic to make @Other::ISA’s existing magic now point to *ISA’s stash. I skipped that logic if *Other::ISA did not contain an array. But in so doing, I inadvertently skipped the call to mro_isa_changed_in at the same time.
* Eliminate PL_OP_SLAB_ALLOCFather Chrysostomos2012-07-121-5/+0
| | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* document the append parameter to sv_gets [perl #72244]Jesse Luehrs2012-07-051-1/+4
|
* sv.c: Correct commentFather Chrysostomos2012-07-031-1/+1
| | | | S_varname is no longer static.
* s/thinngy/thingy/ in a comment in sv.cNicholas Clark2012-07-021-1/+1
|
* handy.h: Fix isBLANK_uni and isBLANK_utf8Karl Williamson2012-06-291-0/+1
| | | | | | | | | | These macros have never worked outside the Latin1 range, so this extends them to work. There are no tests I could find for things in handy.h, except that many of them are called all over the place during the normal course of events. This commit adds a new file for such testing, containing for now only with a few tests for the isBLANK's
* CV-based slab allocation for opsFather Chrysostomos2012-06-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Don’t create pads for sub stubsFather Chrysostomos2012-06-151-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Two code paths, sv_2cv (for \&name) and get_cvn_flags (for &{"name"}()) were using start_subparse and newATTRSUB to create a subroutine stub, which is what usually happens for Perl subs (with op trees). This resulted in subs with unused pads attached to them, because start_subparse sets up the pad, which must be accessible dur- ing parsing. One code path, gv_init, which (among other things) reifies a GV after a sub declaration (like ‘sub foo;’, which for efficiency doesn’t create a CV), created the subroutine stub itself, without using start_subparse/newATTRSUB. This commit takes the code from gv_init, makes it more generic so it can apply to the other two cases, puts it in a new function called newSTUB, and makes all three locations call it. Now stub creation should be faster and use less memory. Additionally, this commit causes sv_2cv and get_cvn_flags to bypass bug #107370 (glob stringification not round-tripping properly). They used to stringify the GV and pass the string to newATTRSUB (wrapped in an op, of all things) for it to look up the GV again. While bug been fixed, as it was a side effect of sv_2cv triggering bug #107370.
* eliminate PL_reg_start_tmp, PL_reg_start_tmplDavid Mitchell2012-06-131-13/+0
| | | | | | | | | | | | | | | | | | PL_reg_start_tmp is a global array of temporary parentheses start positions. An element is set when a '(' is first encountered, while when a ')' is seen, the per-regex offs array is updated with the start and end position: the end derived from the position where the ')' was encountered, and the start position derived from PL_reg_start_tmp[n]. This allows us to differentiate between pending and fully-processed captures. Change it so that the tmp start value becomes a third field in the offs array (.start_tmp), along with the existing .start and .end fields. This makes the value now per regex rather than global. Although it uses a bit more memory (the start_tmp values aren't needed after the match has completed), it simplifies the code, and will make it easier to make a (??{}) switch to the new regex without having to dump everything on the save stack.
* eliminate PL_reglast(close)?paren, PL_regoffsDavid Mitchell2012-06-131-9/+0
| | | | | | | | | | | | | | eliminate the three vars PL_reglastcloseparen PL_reglastparen PL_regoffs (which are actually aliases to PL_reg_state struct elements). These three vars always point to the corresponding fields within the currently executing regex; so just access those fields directly instead. This makes switching between regexes with (??{}) simpler: just update rex, and everything automatically references the new fields.
* eliminate PL_reginterp_cntDavid Mitchell2012-06-131-5/+0
| | | | | | This used to be the mechanism to determine whether "use re 'eval'" needed to be in scope; but now that we make a clear distinction between literal and runtime code blocks, it's no longer needed.
* [perl #111610] Trouble with XS-APItest/t/clone-with-stack.tMichael Schroeder2012-06-081-0/+1
| | | | | | | | | | | | | | | | | | | | I ran into a bit of a problem when building perl-5.16.0. 'make test' showed a segfault in ext/XS-APItest/t/clone-with-stack.t. It seems to be caused by accessing already freed memory, it segfaults because I have MALLOC_PERTUBE_ set, thus glibc fills freed memory with some value. Digging deeper, it seems like perl_clone() does not fix the cx's blk_oldcop element when doing context cloning, thus blk_oldcop still points to PL_compiling in the old interp--the calling scope for the BEGIN block being the compilation of the code surrounding it--and the POPBLOCK done in leavesub will copy the data from the old interp to PL_curcop. After fixing this, it still crashed because interp_dup->Iop was zero after the runops_standard() call (which is probably correct as the end of the BEGIN block was reached). So I also added an if statement that checks the pointer.
* [perl #109542] Make num ops treat $1 as "$1"Father Chrysostomos2012-06-071-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Numeric ops were not taking magical variables into account. So $1 (a magical variable) would be treated differently from "$1" (a non-magi- cal variable0. In determining whether to use an integer operation, they would call SvIV_please_nomg, and then check whether the sv was SvIOK as a result. SvIV_please_nomg would call SvIV_nomg if the sv were SvPOK or SvNOK. The problem here is that gmagical variables are never SvIOK, but only SvIOKp. In fact, the private flags are used differently for gmagical and non- magical variables. For non-gmagical variables, the private flag indi- cates that there is a cached value. If the public flag is not set, then the cached value is imprecise. For gmagical variables, imprecise values are never cached; only the private flags are used, and they are equivalent to the public flags on non-gmagical variables. This commit changes SvIV_please_nomg to take gmagical variables into account, using the newly-added sv_gmagical_2iv_please (see the docs for it in the diff). SvIV_please_nomg now returns true or false, not void, since a subsequent SvIOK is not reliable. So ‘SvIV_please_nomg(sv); if(SvIOK)’ becomes ‘if(SvIV_please_nomg(sv))’.
* [perl #78742] Store CopSTASH in a pad under threadsFather Chrysostomos2012-06-041-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, a pointer to the cop’s stash was stored in cop->cop_stash under non-threaded perls, and the name and name length were stored in cop->cop_stashpv and cop->cop_stashlen under ithreads. Consequently, eval "__PACKAGE__" would end up returning the wrong package name under threads if the current package had been assigned over. This commit changes the way cops store their stash under threads. Now it is an offset (cop->cop_stashoff) into the new PL_stashpad array (just a mallocked block), which holds pointers to all stashes that have code compiled in them. I didn’t use the lexical pads, because CopSTASH(cop) won’t work unless PL_curpad is holding the right pad. And things start to get very hairy in pp_caller, since the correct pad isn’t anywhere easily accessible on the context stack (oldcomppad actually referring to the current comppad). The approach I’ve followed uses far less code, too. In addition to fixing the bug, this also saves memory. Instead of allocating a separate PV for every single statement (to hold the stash name), now all lines of code in a package can share the same stashpad slot. So, on a 32-bit OS X, that’s 16 bytes less memory per COP for short package names. Since stashoff is the same size as stashpv, there is no difference there. Each package now needs just 4 bytes in the stashpad for storing a pointer. For speed’s sake PL_stashpadix stores the index of the last-used stashpad offset. So only when switching packages is there a linear search through the stashpad.
* Delete two instance of SvSCREAM_offFather Chrysostomos2012-05-291-2/+0
| | | | that no longer have any effect.
* 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.
* sv.c: Make sv_pvn_force_flags guard against SV_UNDEF_RETURNS_NULL.Brian Fraser2012-05-261-0/+3
| | | | | | | Previously, if SV_UNDEF_RETURNS_NULL was passed to sv_pvn_force_flags, it would call sv_2pv_flags with that flag, and get back a NULL instead of a char *, which lead to issues. This commit makes sv_pvn_force_flags use an empty string in that case.
* [perl #112786] Fix build under clang++Craig A. Berry2012-05-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A line of code in sv.c last modified at <http://perl5.git.perl.org/perl.git/commit/c6fb3f6e3e5160581b7?f=sv.c> causes clang++ to fall down hard when building blead: sv.c:13969:32: error: unexpected ':' in nested name specifier CV * const cv = gv ? (CV *)gv : find_runcv(NULL); ^ :: sv.c:13969:34: error: no member named 'Perl_find_runcv' in 'gv' CV * const cv = gv ? (CV *)gv : find_runcv(NULL); ~~~~ ^ ./embed.h:137:24: note: expanded from macro 'find_runcv' #define find_runcv(a) Perl_find_runcv(aTHX_ a) ^ sv.c:13969:50: error: expected ':' CV * const cv = gv ? (CV *)gv : find_runcv(NULL); ^ : sv.c:13969:21: note: to match this '?' CV * const cv = gv ? (CV *)gv : find_runcv(NULL); ^ sv.c:13969:50: error: expected expression CV * const cv = gv ? (CV *)gv : find_runcv(NULL); ^ 14 warnings and 4 errors generated. make: *** [sv.o] Error 1 clang++ seems to need only an extra set of parentheses to calm down and let go of its anxieties. [Committer’s note: Leon Timmermans points out that it's struct gv that's confusing clang++. So a struct name used as a variable cannot be followed by a colon.]
* Excise PL_amagic_generationFather Chrysostomos2012-05-231-2/+0
| | | | | | | | | The core is not using it any more. Every CPAN module that increments it also does newXS, which triggers mro_method_changed_in, which is sufficient; so nothing will break. So, to keep those modules compiling, PL_amagic_generation is now an alias to PL_na outside the core.
* sv.c: Don’t do SvAMAGIC_off in newSVrvFather Chrysostomos2012-05-211-1/+0
| | | | | | This has been useless since the flag was moved to the referent in com- mit dd2eae66. rv is undefined by the time this statement is reached if it was a reference.
* sv.c: Don’t do SvAMAGIC_off in sv_setsv_flagsFather Chrysostomos2012-05-211-1/+0
| | | | | | This has been useless since the flag was moved to the referent in com- mit dd2eae66. dstr is undefined by the time this statement is reached if it was a reference.
* sv.c: Don’t fiddle with AMAGIC in sv_blessFather Chrysostomos2012-05-211-5/+0
| | | | | | | Since overloading itself now checks whether caches are up to date, and since changes to the stash (@ISA, methods) turn the flag on and over- loading itself turns the flag off when it can, sv_bless no longer needs to deal with it at all.
* Don’t stringify GV in numeric cx outside warnings scopeFather Chrysostomos2012-05-211-4/+4
| | | | | The GV is only stringified for the sake of the warning message, so there is no point in wasting CPU cycle if it will be unused.
* clear magic flags in sv_clearDavid Mitchell2012-03-261-0/+1
| | | | | | | | | commit 5bec93bead1c10563a402404de095bbdf398790f made temporary use of the no-longer used SvMAGIC field while freeing a HV. This commit makes sure that before this happens, that the SvMAGICAL flags are turned off. This is because it turns out that some XS code (e.g. Glib) can leave an SV with a null SvMAGIC field, but with magic flags still set.
* fix slowdown in nested hash freeingDavid Mitchell2012-03-061-12/+9
| | | | | | | | | | | | | | Commit 104d7b69 made sv_clear free hashes iteratively rather than recursively; however, my code didn't record the current hash index when freeing a nested hash, which made the code go quadratic when freeing a large hash with inner hashes, e.g.: my $r; $r->{$_} = { a => 1 } for 1..10_0000; This was noticeable on such things as CPAN.pm being very slow to exit. This commit fixes this by squirrelling away the old hash index in the now-unused SvMAGIC field of the hash being freed.
* Remove gete?[ug]id cachingÆvar Arnfjörð Bjarmason2012-02-181-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we cache the UID/GID and effective UID/GID similarly to how we used to cache getpid() before v5.14.0-251-g0e21945. Remove this magical behavior in favor of always calling getpid(), getgid() etc. This resolves RT #96208. A minimal testcase for this is the following by Leon Timmermans attached to RT #96208: eval { require 'syscall.ph'; 1 } or eval { require 'sys/syscall.ph'; 1 } or die $@; if (syscall(&SYS_setuid, $ARGV[0] + 0 || 1000) >= 0 or die "$!") { printf "\$< = %d, getuid = %d\n", $<, syscall(&SYS_getuid); } I.e. if we call the sete?[ug]id() functions unbeknownst to perl the $<, $>, $( and $) variables won't be updated. This results in the same sort of issues we had with $$ before v5.14.0-251-g0e21945, and getppid() before my v5.15.7-407-gd7c042c patch. I'm completely eliminating the PL_egid, PL_euid, PL_gid and PL_uid variables as part of this patch, this will break some CPAN modules, but it'll be really easy before the v5.16.0 final to reinstate them. I'd like to remove them to see what breaks, and how easy it is to fix it. These variables are not part of the public API, and the modules using them could either use the Perl_gete?[ug]id() functions or are working around the bug I'm fixing with this commit. The new PL_delaymagic_(egid|euid|gid|uid) variables I'm adding are *only* intended to be used internally in the interpreter to facilitate the delaymagic in Perl_pp_sassign. There's probably some way not to export these to programs that embed perl, but I haven't found out how to do that.
* correctly clone eval context framesZefram2012-02-181-0/+3
| | | | | | When cloning stacks (only used for Win32 fork emulation, not for ordinary threads), the CV referenced by an eval context frame wasn't being cloned. This led to crashes when Win32 forked inside an eval [perl #109718].
* In Perl_sv_del_backref(), don't panic if tsv is already freed.Nicholas Clark2012-02-171-0/+24
| | | | | | During global destruction it's possible for tsv, the target of this weak reference, to already be freed. This isn't a bug, and hence the interpreter should not panic.
* perl #77654: quotemeta quotes non-ASCII consistentlyKarl Williamson2012-02-151-0/+1
| | | | | | | | | | As described in the pod changes in this commit, this changes quotemeta() to consistenly quote non-ASCII characters when used under unicode_strings. The behavior is changed for these and UTF-8 encoded strings to more closely align with Unicode's recommendations. The end result is that we *could* at some future point start using other characters as metacharacters than the 12 we do now.
* Further eliminate POSIX-emulation under LinuxThreadsÆvar Arnfjörð Bjarmason2012-02-151-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under POSIX threads the getpid() and getppid() functions return the same values across multiple threads, i.e. threads don't have their own PID's. This is not the case under the obsolete LinuxThreads where each thread has a different PID, so getpid() and getppid() will return different values across threads. Ever since the first perl 5.0 we've returned POSIX-consistent semantics for $$, until v5.14.0-251-g0e21945 when the getpid() cache was removed. In 5.8.1 Rafael added further explicit POSIX emulation in perl-5.8.0-133-g4d76a34 [1] by explicitly caching getppid(), so that multiple threads would always return the same value. I don't think all this effort to emulate POSIX sematics is worth it. I think $$ and getppid() are OS-level functions that should always return the same as their C equivalents. I shouldn't have to use a module like Linux::Pid to get the OS version of the return values. This is pretty much a complete non-issue in practice these days, LinuxThreads was a Linux 2.4 thread implementation that nobody maintains anymore[2], all modern Linux distros use NPTL threads which don't suffer from this discrepancy. Debian GNU/kFreeBSD does use LinuxThreads in the 6.0 release, but they too will be moving away from it in future releases, and really, nobody uses Debian GNU/kFreeBSD anyway. This caching makes it unnecessarily tedious to fork an embedded Perl interpreter. When someone that constructs an embedded perl interpreter and forks their application, the fork(2) system call isn't going to run Perl_pp_fork(), and thus the return value of $$ and getppid() doesn't reflect the current process. See [3] for a bug in uWSGI related to this, and Perl::AfterFork on the CPAN for XS code that you need to run after forking a PerlInterpreter unbeknownst to perl. We've already been failing the tests in t/op/getpid.t on these Linux systems that nobody apparently uses, the Debian GNU/kFreeBSD users did notice and filed #96270, this patch fixes that failure by changing the tests to test for different behavior under LinuxThreads, I've tested that this works on my Debian GNU/kFreeBSD 6.0.4 virtual machine. If this change is found to be unacceptable (i.e. we want to continue to emulate POSIX thread semantics for the sake of LinuxThreads) we also need to revert v5.14.0-251-g0e21945, because currently we're only emulating POSIX semantics for getppid(), not getpid(). But I don't think we should do that, both v5.14.0-251-g0e21945 and this commit are awesome. This commit includes a change to embedvar.h made by "make regen_headers". 1. http://www.nntp.perl.org/group/perl.perl5.porters/2002/08/msg64603.html 2. http://pauillac.inria.fr/~xleroy/linuxthreads/ 3. http://projects.unbit.it/uwsgi/ticket/85
* Clarify the newSVpvn documentation.Shlomi Fish2012-02-151-6/+8
| | | | | "string" is now called "buffer", and we mention that it might contain NUL characters.
* regcomp.c: /[[:lower:]]/i should match the same as /\p{Lower}/iKarl Williamson2012-02-111-0/+2
| | | | | | Same for [[:upper:]] and \p{Upper}. These were matching instead all of [[:alpha:]] or \p{Alpha}. What /\p{Lower}/i and /\p{Upper}/i match instead is \p{Cased}, and so that is what these should match.
View Lorry Controller Status