summaryrefslogtreecommitdiff
path: root/pp.h
Commit message (Collapse)AuthorAgeFilesLines
* make gimme consistently U8David Mitchell2016-02-031-1/+1
| | | | | | | | | | | | | The value of gimme stored in the context stack is U8. Make all other uses in the main core consistent with this. My primary motivation on this was that the new function cx_pushblock(), which I gave a 'U8 gimme' parameter, was generating warnings where callers were passing I32 gimme vars to it. Rather than play whack-a-mole, it seemed simpler to just uniformly use U8 everywhere. Porting/bench.pl shows a consistent reduction of about 2 instructions on the loop and sub benchmarks, so this change isn't harming performance.
* reformat the FOOMARK macros slightlyDavid Mitchell2015-11-281-5/+12
| | | | whitespace-only changes
* FOOMARK debugging macros: fix %d cast; only -DsvDavid Mitchell2015-11-281-8/+12
| | | | | | | The debugging variants of POPMARK() etc: use %IVdf rather than %d to avoid compiler warnings when sizeof(IV) != sizeof(int); also, make these macros trigger only under -Dsv rather than just -Ds (-v is the verbose variant).
* [perl #126635] don't shortcut when SVf_IVisUV is setTony Cook2015-11-241-2/+2
| | | | | | | Most integers are small, so in most cases it won't be set. The other option would be to always clear it, but that increases the amount of inline code for a rare case.
* silence compiler warnings using INCMARK/POPMARKDavid Mitchell2015-11-191-9/+9
| | | | | | | | | | v5.23.3-305-g6cae08a introduced debugging variants of INCMARK/POPMARK, and replaced a number of "PL_markstack_ptr--;" with "POPMARK;" etc. This spews a bunch of "value computed is not used" warnings; so add some "(void)"s. Also indent the new definitions of INCMARK/POPMARK correctly.
* make SETi/u/n, (X)PUSHi/u/n more efficientDavid Mitchell2015-11-101-9/+75
| | | | | | | | | | | | | | | | | | | | | | | | | These macros are used by many pp functions to set TARG to an int or float value and put it on the stack. The macros use a call to sv_setiv() or similar. However, there is a good chance that the target is ether a lexical var or a PADTMP that has been assigned just an IV/NV in the past, in which case its body is likely to still be of type SVt_IV/SVt_NV. If this is the case, we can set its value much more efficiently. Update those setting macros to first check if the target has a simple body, and if so, set directly. This makes quite a significant performance difference on code that does a lot of arithmetic, at the cost of a larger binary (0.36% on my Linux x86_64 system). It also allows you (at compile time) to skip testing for taint if you know that the value can't be tainted (e.g. pp_add() when both args are non-magical and so can't have taint magic attached). The next commit will make use of this. Includes a couple of efficiency tweaks suggested by Daniel Dragan.
* MARK -Ds debuggingReini Urban2015-11-101-11/+42
| | | | | display the MARK arity and pointers with MARK macros. assert on markptr underflow.
* make EXTEND() and stack_grow() safe(r)David Mitchell2015-10-021-9/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes various issues around stack_grow() and its two main wrappers, EXTEND() and MEXTEND(). In particular it behaves very badly on systems with 32-bit pointers but 64-bit ints. One noticeable effect of this is commit is that various usages of EXTEND() etc will now start to give compiler warnings - usually because they're passing an unsigned N arg when it should be signed. This may indicate a logic error in the caller's code which needs fixing. This commit causes several such warnings to appear in core code, which will be fixed in the next commit. Essentially there are several potential false negatives in this basic code: if (PL_stack_max - p < (SSize_t)(n)) stack_grow(sp,p,(SSize_t)(n)); where it incorrectly skips the call to stack_grow() and then the caller tramples over the end of the stack because it assumes that it has in fact been extended. The value of N passed to stack_grow() can also potentially get truncated or wrapped. Note that the N arg of stack_grow() is SSize_t and EXTEND()'s N arg is documented as SSize_t. In earlier times, they were both ints. Significantly, this means that they are both signed, and always have been. In detail, the problems and their solutions are: 1) N is a signed value: if negative, it could be an indication of a caller's invalid logic or wrapping in the caller's code. This should trigger a panic. Make it so by adding an extra test to EXTEND() to always call stack_grow if negative, then add a check and panic in stack_grow() (and other places too). This extra test will be constant folded when EXTEND() is called with a literal N. 2) If the caller passes an unsigned value of N, then the comparison is between a signed and an unsigned value, leading to potential wrap-around. Casting N to SSize_t merely hides any compiler warnings, thus failing to alert the caller to a problem with their code. In addition, where sizeof(N) > sizeof(SSize_t), the cast may truncate N, again leading to false negatives. The solution is to remove the cast, and let the caller deal with any compiler warnings that result. 3) Similarly, casting stack_grow()'s N arg can hide any warnings issued by e.g. -Wconversion. So remove it. It still does the wrong thing if the caller uses a non-signed type (usually a panic in stack_grow()), but coders have slightly more chance of spotting issues at compile time now. 4) If sizeof(N) > sizeof(SSize_t), then the N arg to stack_grow() may get truncated or sign-swapped. Add a test for this (basically that N is too big to fit in a SSize_t); for simplicity, in this case just set N to -1 so that stack_grow() panics shortly afterwards. In platforms where this can't happen, the test is constant folded away. With all these changes, the macro now looks in essence like: if ( n < 0 || PL_stack_max - p < n) stack_grow(sp,p, (sizeof(n) > sizeof(SSize_t) && ((SSize_t)(n) != n) ? -1 : n));
* perlapi, perlintern: Add L<> links to podKarl Williamson2015-09-031-39/+45
|
* [perl #120903] perlcall cleanupTony Cook2015-09-021-0/+6
| | | | | | | | | | | | | | | | | | | - linkify references to sections - use EXTEND(SP, n) and PUSHs() instead of XPUSHs() where applicable and update prose to match - add POPu, POPul and POPpbytex to the "complete list of POP macros" and clarify the documentation for some of the existing entries, and a note about side-effects - add API documentation for POPu and POPul - use ERRSV more efficiently - approaches to thread-safety storage of SVs. - minor updates
* fix signed/unsigned mismatch in (M)EXTENDHugo van der Sanden2015-03-251-4/+4
| | | | | A large enough allocation request could wrap, causing MEXTEND to decide the stack was already big enough.
* Replace common Emacs file-local variables with dir-localsDagfinn Ilmari Mannsåker2015-03-221-6/+0
| | | | | | | | | | | | | | | | An empty cpan/.dir-locals.el stops Emacs using the core defaults for code imported from CPAN. Committer's work: To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed to be incremented in many files, including throughout dist/PathTools. perldelta entry for module updates. Add two Emacs control files to MANIFEST; re-sort MANIFEST. For: RT #124119.
* 5th arg to indicate numeric bitwise overloadingFather Chrysostomos2015-01-311-0/+1
|
* Add string- and number-specific bitop typesFather Chrysostomos2015-01-311-0/+1
| | | | | and also implement the pp functions, though nothing compiles to these ops yet.
* 01234567890123456789012345678901234567890123456789Father Chrysostomos2014-12-191-1/+1
| | | | | | | pp.h: Remove stack-popping from void overload code There is no need to pop the stack in void context, as every void-context op is followed by something that resets the stack.
* Use full name for Perl_tmps_grow_p in EXTEND_MORTALFather Chrysostomos2014-10-121-1/+1
| | | | | For functions only exported and not public, we can’t use the short forms in pubic macros.
* optimize & rmv from public API Perl_tmps_grow and related codeDaniel Dragan2014-10-101-3/+4
| | | | | | | | | | | | | | | | | | | Previously in PUSH_EXTEND_MORTAL__SV_C, "PL_tmps_ix + 1" would execute twice, once for the nonmutable if(>=), then again after the potential tmps_grow call. tmps_grow has an unused return register/void proto, put it to use by returning ix. Also change tmps_grow to take the result of "PL_tmps_ix + the constant (usually 1) or non-constant (EXTEND_MORTAL)". This avoid having to put the constant twice in machine code, once for the if test, 2nd time for extend length param for tmps_grow call. For non-constant/EXTEND_MORTAL usage, it allows the C optimizer to have the length var to go out of liveness sooner if possible. Also the var used for the if(>=) test is more likely to be in a register than length var. So "if test variable" is closer on hand to the CPU than length var. In some cases, if non-const len var isn't used again, it becomes the "ix" variable by having PL_tmps_ix added to it. Change sv_2mortal to return sv instead of NULL to remove a unique branch/block of machine code that assigns 0 to return variable (Visual C didn't figure out return sv == returned NULL, not sv). See also [perl #121845].
* pp.h: Remove SETsv and SETsvUNFather Chrysostomos2014-09-211-9/+0
| | | | | | | With commit 6f1401dc2a, most of the old overload macros stopped being used. d4f7673c78 removed them. SETsv and SETsvUN were only used by the removed macros, and are now completetly unused in core and on CPAN.
* pp.h: remove spurious comment about OPpTARGET_MYDavid Mitchell2014-09-191-1/+0
| | | | OPpTARGET_MY is unrelated to MAXARG as far as I can tell.
* Automate processing of op_private flagsDavid Mitchell2014-09-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new config file, regen/op_private, which contains all the information about the flags and descriptions for the OP op_private field. Previously, the flags themselves were defined in op.h, accompanied by textual descriptions (sometimes inaccurate or incomplete). For display purposes, there were short labels for each flag found in Concise.pm, and another set of labels for Perl_do_op_dump() in dump.c. These two sets of labels differed from each other in spelling (e.g. REFC verses REFCOUNT), and differed in completeness and accuracy. With this commit, all the data to generate the defines and the labels is derived from a single source, and are generated automatically by 'make regen'. It also contains complete data on which bits are used for what by each op. So any attempt to add a new flag for a particular op where that bit is already in use, will raise an error in make regen. This compares to the previous practice of reading the descriptions in op.h and hoping for the best. It also makes use of data in regen/opcodes: for example, regen/op_private specifies that all ops flagged as 'T' get the OPpTARGET_MY flag. Since the set of labels used by Concise and Perl_do_op_dump() differed, I've standardised on the Concise version. Thus this commit changes the output produced by Concise only marginally, while Perl_do_op_dump() is considerably different. As well as the change in labels (and missing labels), Perl_do_op_dump() formerly had a bug whereby any unrecognised bits would not be shown if there was at least one recognised bit. So while Concise displayed (and still does) "LVINTRO,2", Perl_do_op_dump() has changed: - PRIVATE = (INTRO) + PRIVATE = (LVINTRO,0x2) Concise has mainly changed in that a few op/bit combinations weren't being shown symbolically, and now are. I've avoiding fixing the ones that would break tests; they'll be fixed up in the next few commits. A few new OPp* flags have been added: OPpARG1_MASK OPpARG2_MASK OPpARG3_MASK OPpARG4_MASK OPpHINT_M_VMSISH_STATUS OPpHINT_M_VMSISH_TIME OPpHINT_STRICT_REFS The last three are analogues for existing HINT_* flags. The former four reflect that many ops some of the lower few bits of op_private to indicate how many args the op expects. While (for now) this is still displayed as, e.g. "LVINTRO,2", the definitions in regen/op_private now fully account for which ops use which bits for the arg count. There is a new module, B::Op_private, which allows this new data to be accessed from Perl. For example, use B::Op_private; my $name = $B::Op_private::bits{aelem}{7}; # OPpLVAL_INTRO my $value = $B::Op_private::defines{$name}; # 128 my $label = $B::Op_private::labels{$name}; # LVINTRO There are several new constant PL_* tables. PL_op_private_valid[] specifies for each op number, which bits are valid for that op. In a couple of commits' time, op_free() will use this on debugging builds to assert that no ops gained any private flags which we don't know about. In fact it was by using such a temporary assert repeatedly against the test suite, that I tracked down most of the inconsistencies and errors in the current flag data. The other PL_op_private_* tables contain a compact representation of all the ops/bits/labels in a format suitable for Perl_do_op_dump() to decode Op_private. Overall, the perl binary is about 500 bytes smaller on my system.
* remove 1 read of interp var from PUSHMARKDaniel Dragan2014-06-091-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | PL_markstack_ptr was read once to do the ++ and comparison. Then after the markstack_grow call, or not, depending on the branch. The code reads PL_markstack_ptr a 2nd time. It has to be reread in case (or always does) markstack_grow reallocs the mark stack. markstack_grow has a void retval. That is a waste of a register. Let us put it to use to return the new PL_markstack_ptr. In markstack_grow the contents that will be assigned to PL_markstack_ptr are already in a register. So let the I32* flow out from markstack_grow to its caller. In VC2003 32 bit asm, mark_stack_entry is register eax. The retval of markstack_grow is in eax. So the assignment "=" in "mark_stack_entry = markstack_grow();" has no overhead. Since the other, not extend branch, is function call free, "(mark_stack_entry = ++PL_markstack_ptr)" assigns to eax. Ultimatly with this patch a 3 byte mov instruction is saved for each instance of PUSHMARK, and 1 interp var read is removed. I observed 42 callers of markstack_grow with my disassembler, so theoretically 3*42 bytes of machine code was removed for me. Perl_pp_pushmark dropped from 0x2b to 0x28 bytes of x86 VC 2003 machine code. [perl #122034]
* Fixup for [perl #121860]: g++ and VC are pickier about what'sJarkko Hietaniemi2014-05-281-1/+1
| | | | an expression and what's a statement.
* Fix EXTEND changes under STRESS_REALLOCSteffen Mueller2014-05-281-2/+2
| | | | | As part of aad79b331c21c962b6e0ce7b8027aa625d7445ec, -DSTRESS_REALLOC was broken. This should alleviate that.
* Avoid "unused sp" if EXTEND is the last mentioning sp.Jarkko Hietaniemi2014-05-281-14/+22
| | | | | | | | Add PERL_UNUSED_VAR(sp) in case the EXTEND (or MEXTEND) is the last thing mentioning the sp. Addresses Coverity perl5 CIDs 29199..29201, 29204, 29205, 29206, 29208, 29210, 29212, 29213, 29215, 29216, 29219..29221.
* sprinkle LIKELY() on pp_hot.c scope.c and some *.hDavid Mitchell2014-03-121-5/+6
| | | | | | | | I've gone through pp_hot.c and scope.c and added LIKELY() or UNLIKELY() to all conditionals where I understand the code well enough to know that a particular branch is or isn't likely to be taken very often. I also processed some of the .h files which contain commonly used macros.
* Change av_len calls to av_tindex for clarityKarl Williamson2014-02-201-1/+1
| | | | | | av_tindex is a more clearly named synonym for av_len, available starting in v5.18. This changes the core uses to it, including modules in /ext, which are not dual-lifed.
* Consistent spaces after dots in perlintern.podFather Chrysostomos2013-12-291-1/+1
|
* perlapi: Consistent spaces after dotsFather Chrysostomos2013-12-291-1/+1
| | | | plus some typo fixes. I probably changed some things in perlintern, too.
* Extend STRESS_REALLOC to move the stack with every EXTENDFather Chrysostomos2013-11-221-2/+12
| | | | | | This allows us easily to catch cases where the stack could move to a new memory address while code still holds pointers to the old loca- tion. Indeed, this causes test failures.
* Eliminate POPq, POPuq, TOPq, TOPuq, dPOPqv, dTOPqv, qPOPuqv, dTOPuqv.Nicholas Clark2013-09-171-14/+0
| | | | | | These shortcut macros are unused in the core, and unused by any code on CPAN. If any XS code we can't see *is* using them, it will now fail to compile, and can easily be fixed by replacing the macros with their expansion.
* Use SSize_t for arraysFather Chrysostomos2013-08-251-2/+2
| | | | | | | | | | Make the array interface 64-bit safe by using SSize_t instead of I32 for array indices. This is based on a patch by Chip Salzenberg. This completes what the previous commit began when it changed av_extend.
* Use SSize_t when extending the stackFather Chrysostomos2013-08-251-4/+4
| | | | | | | | | | | | | | | | (I am referring to what is usually known simply as The Stack.) This partially fixes #119161. By casting the argument to int, we can end up truncating/wrapping it on 64-bit systems, so EXTEND(SP, 2147483648) translates into EXTEND(SP, -1), which does not extend the stack at all. Then writing to the stack in code like ()=1..1000000000000 goes past the end of allocated memory and crashes. I can’t really write a test for this, since instead of crashing it will use more memory than I have available (and then I’ll start for- getting things).
* (UN)LIKELY branch prediction hints in a few strategic placesSteffen Mueller2013-03-061-7/+7
| | | | | | | | This adds branch prediction hints to a few strategic places such as growing stack or strings, some exception handling, and a few hot functions such as sv_upgrade. This is not exhaustive by any means.
* Remove the second param to tryAMAGICunTARGETlistFather Chrysostomos2012-12-091-3/+2
| | | | This parameter is no longer used. Its value is always 0.
* pp.h: Remove tryAMAGICunTARGETFather Chrysostomos2012-12-091-7/+4
| | | | | This macro is unused on CPAN and completely undocumented, so this change should be safe.
* Remove "register" declarationsKarl Williamson2012-11-241-1/+1
| | | | | | | This finishes the removal of register declarations started by eb578fdb5569b91c28466a4d1939e381ff6ceaf4. It neglected the ones in function parameter declarations, and didn't include things in dist, ext, and lib, which this does include
* Fix format closure bug with redefined outer subFather Chrysostomos2012-08-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CVs close over their outer CVs. So, when you write: my $x = 52; sub foo { sub bar { sub baz { $x } } } baz’s CvOUTSIDE pointer points to bar, bar’s CvOUTSIDE points to foo, and foo’s to the main cv. When the inner reference to $x is looked up, the CvOUTSIDE chain is followed, and each sub’s pad is looked at to see if it has an $x. (This happens at compile time.) It can happen that bar is undefined and then redefined: undef &bar; eval 'sub bar { my $x = 34 }'; After this, baz will still refer to the main cv’s $x (52), but, if baz had ‘eval '$x'’ instead of just $x, it would see the new bar’s $x. (It’s not really a new bar, as its refaddr is the same, but it has a new body.) This particular case is harmless, and is obscure enough that we could define it any way we want, and it could still be considered correct. The real problem happens when CVs are cloned. When a CV is cloned, its name pad already contains the offsets into the parent pad where the values are to be found. If the outer CV has been undefined and redefined, those pad offsets can be com- pletely bogus. Normally, a CV cannot be cloned except when its outer CV is running. And the outer CV cannot have been undefined without also throwing away the op that would have cloned the prototype. But formats can be cloned when the outer CV is not running. So it is possible for cloned formats to close over bogus entries in a new parent pad. In this example, \$x gives us an array ref. It shows ARRAY(0xbaff1ed) instead of SCALAR(0xdeafbee): sub foo { my $x; format = @ ($x,warn \$x)[0] . } undef &foo; eval 'sub foo { my @x; write }'; foo __END__ And if the offset that the format’s pad closes over is beyond the end of the parent’s new pad, we can even get a crash, as in this case: eval 'sub foo {' . '{my ($a,$b,$c,$d,$e,$f,$g,$h,$i,$j,$k,$l,$m,$n,$o,$p,$q,$r,$s,$t,$u)}'x999 . q| my $x; format = @ ($x,warn \$x)[0] . } |; undef &foo; eval 'sub foo { my @x; my $x = 34; write }'; foo(); __END__ So now, instead of using CvROOT to identify clones of CvOUTSIDE(format), we use the padlist ID instead. Padlists don’t actually have an ID, so we give them one. Any time a sub is cloned, the new padlist gets the same ID as the old. The format needs to remember what its outer sub’s padlist ID was, so we put that in the padlist struct, too.
* pp.h: Make [TP]OPp and [TP]OPpx identicalFather Chrysostomos2012-07-271-4/+5
| | | | | | In the absence of n_a (see 8c074e2a and 95fad918), there is no differ- ence between [TP]OPp and [TP]OPpx except speed, so there is no reason for the x-less variant to be deprecated.
* Use find_runcv_where for pp_coreargs and pp_runcvFather Chrysostomos2012-07-021-0/+1
|
* Make formats close over the right closureFather Chrysostomos2012-06-291-0/+2
| | | | | | | | | | | | | | | | | 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.
* propagate context into overloads [perl #47119]Jesse Luehrs2012-06-281-7/+28
| | | | | | | | | | | | | | | | | amagic_call now does its best to propagate the operator's context into the overload callback. It's not always possible - for instance, dereferencing and stringify/boolify/numify always have to return a value, even if it's not used, due to the way the overload callback works in those cases - but the majority of cases should now work. In particular, overloading <> to handle list context properly is now possible. For backcompat reasons (amagic_call and friends are technically public api functions), list context will not be propagated unless specifically requested via the AMGf_want_list flag. If this is passed, and the operator is called in list context, amagic_call returns an AV* holding all of the returned values instead of an SV*. Void context always results in amagic_call returning &PL_sv_undef.
* [perl #112966] Crash on delete local; other local bugsFather Chrysostomos2012-06-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit bee7c5743fa appears to have fixed this. But what it does is barely significant: diff --git a/sv.c b/sv.c index b96f7c1..a4994f5 100644 --- a/sv.c +++ b/sv.c @@ -9525,6 +9525,11 @@ Perl_sv_bless(pTHX_ SV *const sv, HV *const stash) SvUPGRADE(tmpRef, SVt_PVMG); SvSTASH_set(tmpRef, MUTABLE_HV(SvREFCNT_inc_simple(stash))); + if (Gv_AMG(stash)) + SvAMAGIC_on(sv); + else + (void)SvAMAGIC_off(sv); + if(SvSMAGICAL(tmpRef)) if(mg_find(tmpRef, PERL_MAGIC_ext) || mg_find(tmpRef, PERL_MAGIC_uvar)) mg_set(tmpRef); The crash can still be triggered another way. Instead of a blessing, we need to modify a method (to turn on the potentially-overloaded flag) and then use an operator that respects overloading. This exam- ple crashes before and after bee7c5743fa: eval 'sub Sample::foo {}'; "".bless {},'Sample'; delete local $Sample::{ '()' }; It is the recalculation of overload caches before a localised deletion that causes the crash. And it only happens when the '()' key does not exist. Actually, it turns out that S_delete_local doesn’t behave correctly for rmagical aggregates, except for %ENV: $ ./perl -Ilib -MDevel::Peek -e 'delete local $ISA[0]' Bus error $ ./perl -XIlib -MDevel::Peek -e '??; delete local $::{foo}' Bus error It’s this line, which occurs twice in pp.c:S_do_delete_local, which is at fault: const bool can_preserve = SvCANEXISTDELETE(osv) || mg_find((const SV *)osv, PERL_MAGIC_env); When can_preserve is true, the ‘preeminent’ variable is set based on whether the element exists. Otherwise it is set to true. Why the term ‘preeminent’ was chosen I don’t know, but in this case it means that the element already exists, so it has to be restored after- wards. We can’t just do save_delete. The code for saving a hash element assumes it is non-null, and crashes otherwise. The logic for setting can_preserve is wrong. SvCANEXISTDELETE returns true for non-magical variables and for variables with those tie meth- ods implemented. For magical variables that are not tied, it returns the wrong answer. PERL_MAGIC_env seems to have been added as an exception, to keep it working. But other magical aggregates were not accounted for. This logic was copied from other functions (aslice, hslice, etc.), which are similarly buggy, but they don’t crash: $ ./perl -Ilib -le ' { local $::{foo} } print exists $::{foo}' $ ./perl -Ilib -le 'm??; { local $::{foo} } print exists $::{foo}' 1 In all these cases, it is SvCANEXISTDELETE that is buggy. So this commit fixes it and adds tests for all the code paths that use it. Now no exception needs to be made for PERL_MAGIC_env.
* 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.
* Fix non-GCC compilationFather Chrysostomos2012-05-211-4/+3
| | | | I mistakenly thought XPUSHs(...) was an expression. Now it is.
* pp.h: Missing macro parenthesesFather Chrysostomos2012-05-211-1/+1
| | | | This wasn’t affecting anything, but was a bug waiting to happen.
* [perl #44895] += warning on uninit magic varFather Chrysostomos2012-01-091-1/+1
| | | | | | | | | | | | | | The only uses of USE_LEFT in core now occur when SvGETMAGIC has already been called. So returning true for magical SVs is not neces- sary. In fact, it was never correct. Also, the code in do_vop (which handles bitwise operations on strings) to avoid an uninitialized warning had the same buggy SvGMAGICAL check. Now, the warning from $uninit += 1 is suppressed for all undefined vars, not just amagical ones. This causes 6 to-do tests in assignwarn.t to pass.
* Remove magical dPOPXnnrl_ul dPOPXiirl_ul macrosFather Chrysostomos2012-01-091-12/+0
| | | | | | These are undocumented and unused on CPAN and in the core. The core now uses _nomg variants.
* Make filetest ops handle get-magic correctly for glob(ref)sFather Chrysostomos2011-09-101-2/+4
| | | | | | This patch uses the recently-added MAYBE_DEREF_GV macro which puts the glob deref logic in one spot. It also adds _nomg and _flags varia- tions of it. _flags understands the SV_GMAGIC flag.
* Don’t call get-magic on a referenced array in chdir, etc.Father Chrysostomos2011-09-101-1/+2
| | | | | | | | | | | | Commit 557fbd17eb added the MAYBE_DEREF_GV macro, which 2ea1cce applied to chdir, chmod and chown. That macro calls get-magic on its arguments checks to see if it might be a gv or ref and, if it’s a ref, calls get-magic on the referent, to see whether it will turn into a gv. That means we’ll end up with chdir($array_obj) calling get-magic on the array. While probably harmless, calling get-magic is superfluous and probably incorrect. I don’t know that there is a reasonable way to test this.
* Add MAYBE_DEREF_GV macroFather Chrysostomos2011-09-101-0/+13
| | | | | | | | | | | | | | | | | There are so many parts of the core (mostly pp functions or functions they call) that need a glob or a globref, including many that call get-magic at the wrong time (or not at all in some cases, that it makes sense to add a macro to do it. It can be used like this: if (gv = MAYBE_DEREF_GV(sv)) /* calls get-magic */ { } else { /* avoid magic here */ }
View Lorry Controller Status