summaryrefslogtreecommitdiff
path: root/op.c
Commit message (Collapse)AuthorAgeFilesLines
* Convert some uvuni() to uvchr()Karl Williamson2013-08-291-10/+10
| | | | | All the tables are now based on the native character set, so using uvuni() in almost all cases is wrong.
* Use real illegal UTF-8 byteKarl Williamson2013-08-291-10/+8
| | | | | | | | | | | | | | | | The code here was wrong in assuming that \xFF is not legal in UTF-8 encoded strings. It currently doesn't work due to a bug, but that may eventually be fixed: [perl #116867]. The comments are also wrong that all bytes are legal in UTF-EBCDIC. It turns out that in well-formed UTF-8, the bytes C0 and C1 never appear (C2, C3, and C4 as well in UTF-EBCDIC), as they would be the start byte of an illegal overlong sequence. This creates a #define for an illegal byte using one of the real illegal ones, and changes the code to use that. No test is included due to #116867.
* Use new clearer named #definesKarl Williamson2013-08-291-5/+5
| | | | | This converts several areas of code to use the more clearly named macros introduced in the previous commit
* Use SSize_t for arraysFather Chrysostomos2013-08-251-1/+1
| | | | | | | | | | 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 for tmps stack offsetsFather Chrysostomos2013-08-251-1/+1
| | | | | | | | | | | | | | | This is a partial fix for #119161. On 64-bit platforms, I32 is too small to hold offsets into a stack that can grow larger than I32_MAX. What happens is the offsets can wrap so we end up referencing and modifying elements with negative indices, corrupting memory, and causing crashes. With this commit, ()=1..1000000000000 stops crashing immediately. Instead, it gobbles up all your memory first, and then, if your com- puter still survives, crashes. The second crash happesn bcause of a similar bug with the argument stack, which the next commit will take care of.
* [perl #118753] Remove erroneous elsif("") warningFather Chrysostomos2013-08-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | ‘5 || foo’ gets optimised down to a plain ‘5’. If that happens in void context, we should not get a warning, as constant folding is not supposed to change behaviour. We accomplish that by flagging the constant with OPpCONST_SHORTCIRCUIT. The code that warns checks for the absence of that flag first. Commit f6f3a1fea, in order to improve line number accuracy in elsif, changed the condition in elsif() to have a nulled COP (containing line numbers) with the condition as its kidop. That prevented constant folding from happening, so commit 71c4dbc37 implemented a function (search_const) to search to find a constant below the nulled COP, but only used it to make folding happen, and did not use it for OPpCONST_SHORTCIRCUIT. The result was that if($foo){}elsif(""){} (mostly equivalent to $foo ? do{} : "" && do {} internally) got folded to $foo ? do{} : "" without OPpCONST_SHORTCIRCUIT being set on the final "". So the warn- ing occurs. This commit uses search_const to set OPpCONST_SHORTCIRCUIT, and the warning vanishes.
* [perl #118693] Remove PADTMP exemption from uninit warningsFather Chrysostomos2013-08-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a problem with undefined values return from XSUBs not pro- ducing such warnings. The default typemap for XSUBs uses the target of the entersub call (in the caller’s pad) to return the converted value, instead of having to allocate a new SV for that. So, for example, a function returning char* will cause that char* to be assigned to the target via sv_setpv. Then the target is returned. As a special case, NULL return from a char*-returning function will produce an undef return value. This undef return value was not trig- gering an uninitialized warning. All targets are marked PADTMP, and anything marked PADTMP is exempt from uninitialized warnings in some code paths, but not others. This goes all the way back to 91bba347, which suppressed the warning with only a hit at why (something to do with bitwise ops warning inap- propriately). I think it was to make ~undef exempt. But a1afd104 stopped it from being exempt. Only a few pieces of code were relying on this exemption, and it was hiding bugs, too. The last few commits have addressed those, so kiss this exemption good-bye! pp_reverse had a workaround to force an uninit warning (since 1e21d011c), so remove the workaround to avoid a double uninit warning.
* Fix skip logic in pad_tidy and cv_cloneFather Chrysostomos2013-08-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 325e1816dc changed the logic for determining whether a pad entry is to be treated like a constant; i.e., shared between recursion levels and sub clones. According the old logic, a pad entry must be shared if it is marked READONLY or is a shared hash key scalar. According to the new logic, the entry must be shared if the pad name has a zero-length PV (i.e., &PL_sv_no). Two pieces of code were still following the old logic. Changing them fixes this old bug: my $close_over_me; sub { () = $close_over_me; open my $fh, "/dev/null"; print "$$fh\n" }->(); __END__ Output: *main:: The name attached to the implicit rv2gv op in open() was not being copied by sub clones. The previous commit is also part of the fix. In the tests, I tested the combination of sub cloning and recursion, since it seemed like a good idea (and also as a result of copying and pasting :-). S_pmtrans was still relying on the old logic, so it gets changed, too.
* Stop recursion from losing lex fh namesFather Chrysostomos2013-08-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | sub r { r($_[0]-1) if $_[0]; open my $fh, "/dev/null"; print "$_[0] $$fh\n" } r(5); __END__ Output: 0 *main:: 1 *main:: 2 *main:: 3 *main:: 4 *main:: 5 *main::$fh The largest number represents the outermost call. The handle name was being allocated as a target (a scratch variable used by various operators to return values). Targets are not shared between recursion levels. This commit tells pad_alloc to treat it like a constant, so it is shared.
* Mark COWable constants as COWable at compile timeFather Chrysostomos2013-08-121-2/+13
| | | | | | | | | | | | | | | This allows ‘$_ = "hello"’ to do COW without having to copy that constant. The reason this did not work before is that we never do copy-on-write with existing read-only scalars that are not already marked COW, as doing so modifies the string buffer, which the read-only flag may be intended to protect. At compile time, most constants start out mutable and are made read- only in ck_svconst. So there we can check that the constant is indeed still mutable (and COWable) and mark it as a COW scalar before making it read-only.
* Set PL_curcop to NULL in op.c:S_cop_freeFather Chrysostomos2013-08-111-0/+2
| | | | | | | | | | Having PL_curcop pointing to a freed op is a Bad Idea and something that has caused bugs in the past. The intent of commit 1df5f7c195 was to do this, but this part of the commit was accidentally omitted. See <20130805200313.GS3729@plum.flirble.org>.
* Make PL_hints an alias for PL_compiling.cop_hintsFather Chrysostomos2013-08-111-4/+0
| | | | | | | | | | | | | | | | | | | PL_hints stores the hints at compile time that get copied into the cop_hints field of each COP (in newSTATEOP). Since perl-5.8.0-8053-gd5ec298, COPs have stored all the hints. Before that, COPs used to store only some of the hints. The hints were copied here and there into PL_compiling, a static COP-shaped buf- fer used during compilation, so that things like constant folding would see the correct hints. a0ed51b3 back in 1998 did that. Now that COPs can store all the hints, we can just use PL_compiling.cop_hints to avoid having to copy them from PL_hints from time to time. This simplifies the code and avoids creating bugs like those that a547fd219 and 1c75beb82 fixed.
* op.c: Force shared hash key optimisation for existing COWsFather Chrysostomos2013-08-111-2/+2
| | | | | | | | | | | | | | | | | | | | | If COW scalars are becoming more prevalent (they are), the hash key optimisation will be less and less likely to kick in if it is skipped for anything already SvIsCOW. The assumption is that such a scalar is already a shared hash key sca- lar. That is not true for copy-on-write scalars made such by the new mechanism that allows existing non-COW scalar to be upgraded to such. The purpose of using shared hash keys scalars here is that the precom- puted hash is already stored in the scalar (ok, it points to it indi- rectly), speeding up hash lookup. New COW scalars don’t have that and offer no speedup here. So skip the optimisation only when the COW scalar is a shared hash key scalar. All of the above applies to methods as well.
* op.c:ck_svconst: Don’t allow ro COWs under old COWFather Chrysostomos2013-08-111-0/+3
| | | | | | | | | | | | | Under PERL_OLD_COPY_ON_WRITE, allowing COWs to become read-only will complicate things elsewhere. It uses the IV slot of an SV to point to a loop of SVs sharing the same buffer. sv_2iv cannot cache the IV without running the SV through sv_force_normal, but that will croak on read-only values. I could change it to S_sv_uncow, but there are more cases elsewhere that would have to be audited, I don’t think it’s worth spending time on improving PERL_OLD_COPY_ON_WRITE as it’s ‘dead code, never intended to go live’ according to its author. I am bothering with at least this much because I don’t want to break it knowingly.
* Make constant folding use the right hintsFather Chrysostomos2013-08-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was brought up in ticket #117855. PL_compiling is a cop-sized static buffer (inside the interpreter struct under threads) that stores information during compile time (such as file name and line number) that gets copied to each cop (con- trol op; aka state op or nextstate op) as it is created. Some values are not actually stored in PL_compiling, such as the current stash (PL_curstash is used instead) and the current hints (PL_hints is used). The ops in each statement are created before that statement’s cop is created. At run time, each cop is executed at the start of the statement and sets PL_curcop to point to itself, so that operators within that statement can get information from PL_curcop. Constant folding was copying the contents of PL_compiling into a tem- porary cop used to execute the ops being folded. That constant fold- ing happened of course before the cop was created for that statement. Now it just happened that commit a0ed51b321 back in 1998 modified newSTATEOP to copy hints to PL_compiling in addition to the new cop being created. Presumably that was to fix the type of bug that this commit is addressing. (Presumably this commit renders those changes unnecessary.) That meant that most of the time constant folding would see the right hints. That fails, though, when it comes to the first statement in a string eval. When you do eval("uc(ä)"), the constant folding happens when PL_compiling.cop_hints still points to whatever value it had before the eval was executed; i.e., an unpredictable value. Slight changes to unrelated scopes (and, apparently, using a different compiler*) can cause the result of that string eval to change. The solution is to set the hints from PL_hints explicitly when doing constant folding. * <https://rt.perl.org/rt3/Ticket/Display.html?id=117855#txn-1241613>ff. I never got to the bottom of why the compiler would make a diffe- rence here. Finding out would involve setting a watchpoint on PL_compiling.cop_hints in a C debugger and then stepping through the thousands of times PL_compiling changes, which is too much work. Nevertheless, I know this fix is correct, as it changes PL_compiling.cop_hints from having a non-deterministic value during constant folding to having a predictable one.
* Revert "[perl #117855] Store CopFILEGV in a pad under ithreads"Father Chrysostomos2013-08-091-51/+15
| | | | | | | | | | | | This reverts commit c82ecf346. It turn out to be faulty, because a location shared betweens threads (the cop) was holding a reference count on a pad entry in a particu- lar thread. So when you free the cop, how do you know where to do SvREFCNT_dec? In reverting c82ecf346, this commit still preserves the bug fix from 1311cfc0a7b, but shifts it around.
* op.c:ck_eval: remove redundant null checkFather Chrysostomos2013-08-091-5/+2
| | | | op_first is never null when OPf_KIDS is set.
* Don’t stringify undef hash keys at compile timeFather Chrysostomos2013-08-091-1/+1
| | | | | | | | | | | | | | | | | | $ ./perl -wIlib -Mconstant' u=>undef' -e '()=$a{+u} if $a' Use of uninitialized value at -e line 1. Well, I didn’t even execute that hash lookup, so why is it warning me about an uninitialized value? This is a compile-time optimisation to turn hash keys into shared hash key scalars (containing precomputed hashes) to speed up key lookup. It stringifies the hash key at compile time as part of the process. The value should not be stringified if that would cause observable difference with tied hashes. Commit 04698ff67 fixed this for refs, globs and regexps, but missed undef scalars. This could be considered part of bug #79178.
* op.c:newCONSTSUB: Stop using CopFILESV for CvFILEFather Chrysostomos2013-08-051-5/+0
| | | | | | | | | | | | CopFILESV points to *{"_<filename"}, which can be modified from perl space. CopFILE points to the third character of *{"_<filename"}{NAME}. Ithreads were already using CopFILE. Make non-threaded builds do the same. This makes things a little more robust. CvFILE is not actually used anywhere as far as I can tell, so I cannot easily test this.
* op.c:aassign_common_vars: merge duplicate codeFather Chrysostomos2013-08-051-10/+6
| | | | We are just asking for bugs to creep in by repeating it like this.
* op.c: correct commentFather Chrysostomos2013-08-051-1/+1
|
* [perl #117855] Store CopFILEGV in a pad under ithreadsFather Chrysostomos2013-08-051-15/+51
| | | | | | | | | | | | | | | | This saves having to allocate a separate string buffer for every cop (control op; every statement has one). Under non-threaded builds, every cop has a pointer to the GV for that source file, namely *{"_<filename"}. Under threaded builds, the name of the GV used to be stored instead. Now we store an offset into the per-interpreter PL_filegvpad, which points to the GV. This makes no significant speed difference, but it reduces mem- ory usage.
* Revert "[perl #119043] Exempt shared hash key consts from ro"Father Chrysostomos2013-08-031-3/+1
| | | | | | | | | | | | | | | | | | This reverts commit ba36554e02872e48d146177a57a9cfb154727fae. It turns out it reinstates bugs like this: $ perl -e 'for(1..10){for(__PACKAGE__){warn $_; $_++}}' main at -e line 1. maio at -e line 1. maip at -e line 1. maiq at -e line 1. mair at -e line 1. mais at -e line 1. mait at -e line 1. maiu at -e line 1. maiv at -e line 1. maiw at -e line 1.
* [perl #119055] Make qq with no vars read-onlyFather Chrysostomos2013-07-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | In commit 2484f8db I stopped constant folding from changing the read- onliness of expressions like 1+2, which should return mutable values, seeing that ${\1}+2 returns a mutable value. (After all, constant folding is supposed to be solely an optimisation, without changing behaviour.) This is accomplished by turning on the PADTMP flag, which tells opera- tors like \ to copy the scalar. I did not realise at the time that some qq strings like "hello\n" and qq "foo" (but not just "foo") are implemented using constant folding. The lexer outputs something like stringify("foo"), which is compiled down to a stringify op with a constant ("foo") as its only child. In this case we really do want qq"foo" to be treated as a single con- stant. That it is implemented using folding while "foo" is not is an implementation detail we should hide. So turn off the PADTMP flag when folding a stringify op.
* [perl #119043] Exempt shared hash key consts from roFather Chrysostomos2013-07-281-1/+3
| | | | | | | | | | | | Commit 19130678b4 stopped copy-on-write scalars from being exempt from readonliness in ck_svconst (called for every OP_CONST). That was for the sake of consistency. It turns out this breaks CPAN modules, so change it back, but only for shared hash key scalars, not other COW scalars. This is an historical artefact left over from when copy-on-write used the read-only flag without the scalar actually being read-only.
* [perl #119051] Fix crash with \&$glob_copyFather Chrysostomos2013-07-281-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | $ref = *Foo::nosub; \&$ref; The assignment creates a glob copy (coercible glob; one that down- grades back to a simple scalar when assigned to). \&$ref autovivifies a stub in that glob. The CvGV pointer ends up pointing to $ref, rather than *Foo::nosub. $ref can easily cease being a glob. So crashes happen. Stub autovivification used to stringify the glob, look it up again by name, and then vivify the stub in the glob. In commit 186a5ba82d584 I removed what seemed like a waste of CPU cycles, but apparently it served some purpose. The lookup caused CvGV to point to *Foo::nosub, rather than $x. This commit restores the stringfy-and-lookup if the glob is coercible (SvFAKE). It goes a little further and turns off the SvFAKE flag if the glob just looked up is also FAKE. It turns out this bug is old, and has been triggerable via glob copies in stash elements for a long time. 186a5ba82d584 made it easier to trigger the bug (so it is a regression from 5.16).
* Make overloaded constants always read-onlyFather Chrysostomos2013-07-251-1/+1
| | | | | | | They were not read-only if the constant handler returned a shared hash key scalar. This was brought up in bug #109744.
* [perl #79908] Stop sub inlining from breaking closuresFather Chrysostomos2013-07-251-54/+3
| | | | | | | | | | | | | | | | | | | | | | | | When a closure closes over a variable, it references the variable itself, as opposed to taking a snapshot of its value. This was broken by the constant optimisation added for constant.pm’s sake: { my $x; sub () { $x }; # takes a snapshot of the current value of $x } constant.pm no longer uses that mechanism, except on older perls, so we can remove this hack, causing code like this this to start work- ing again: BEGIN{ my $x = 5; *foo = sub(){$x}; $x = 6 } print foo; # now prints 6, not 5
* Make sub(){42} return a mutable valueFather Chrysostomos2013-07-251-0/+2
| | | | | | | | | | | | | | | | But only make it do so in lvalue context. This will be just as fast in true rvalue context. In either case, it is still inlined. This makes sub () { 42 } and sub () { return 42 } do the same thing. It also means that sub () { '-'x75 } reverts back to returning a muta- ble value, the way it did in 5.16. From now on, tweaks to constant folding will no longer affect the mutability of the return value of a nullary function. ‘use constant’ is unaffected. It still returns read-only values. This was brought up in ticket #109744.
* Inline list constantsFather Chrysostomos2013-07-251-0/+11
| | | | | | | | | | | These are inlined the same way as 1..5. We have two ops: rv2av | `-- const The const op returns an AV, which is stored in the op tree, and then rv2av flattens it.
* Allow stash elems to be array refsFather Chrysostomos2013-07-251-2/+35
| | | | | | | | | | | | | | | | | | These turn into CVs that return the contents of the array. Future commits will make constant.pm use these and also make them inlinable. Even without inlining, these subs are faster, because they are XSUBs: $ time ./perl -Ilib -e 'my @a=1..1000000; sub foo { @a } () = foo for 1..10' real 0m3.725s user 0m3.407s sys 0m0.227s $ time ./perl -Ilib -e 'my @a=1..1000000; BEGIN { $::{foo} = \@a } () = foo for 1..10' real 0m2.153s user 0m1.949s sys 0m0.121s
* Stop folding of ops from changing mutabilityFather Chrysostomos2013-07-251-0/+1
| | | | If $a+$b produces a mutable value, then so should 1+2.
* [perl #3105] Make 1..3 modification safeFather Chrysostomos2013-07-251-1/+7
| | | | | | | | | | | This construct is optimised at compile time to an anonymous array with an implicit @{} around it if both arguments are constant. Modifying elements of that array produces wrong results the next time the same code is executed. If we mark each element of the array as PADTMP, then it will be treated like an operator’s return value (which it is) and get copied as appropriate.
* op.c: Stop copying constants under ithreadsFather Chrysostomos2013-07-251-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes bugs #21979, #89188, #109746, #114838 and #115388 and mostly fixes #109744 and #105906 (other issues still remain in those two tickets). Because the PADTMP flag was doing double duty, indicating that a pad slot was in use in addition to indicating a target, constants could not be shared between pad slots, as freeing one const op (and turning of its PADTMP flag in pad_free) would mark some other pad slot as free. I believe this may have been fixed already by change 3b1c21fabed, which made const ops use pad_swipe (which removes the SV from the pad) instead of pad_free (which marks it as available for reuse). But the copying still happens. In any case, as of the previous commit, whether a pad slot for a con- stant is in use is now stored in the pad name. Slots in use for const ops now have &PL_sv_no names. So there is no longer any reason to copy the constants. The difference can be observed thus: Before: $ ./perl -lIlib -MDevel::Peek -e 'sub foo(){42} Dump foo; Dump foo' SV = IV(0x7f94ea02ef10) at 0x7f94ea02ef20 REFCNT = 2 FLAGS = (PADTMP,IOK,READONLY,pIOK) IV = 42 SV = IV(0x7f94ea02eeb0) at 0x7f94ea02eec0 REFCNT = 1 FLAGS = (PADTMP,IOK,READONLY,pIOK) IV = 42 After: $ ./perl -lIlib -MDevel::Peek -e 'sub foo(){42} Dump foo; Dump foo' SV = IV(0x7f894882ef10) at 0x7f894882ef20 REFCNT = 3 FLAGS = (IOK,READONLY,pIOK) IV = 42 SV = IV(0x7f894882ef10) at 0x7f894882ef20 REFCNT = 3 FLAGS = (IOK,READONLY,pIOK) IV = 42 Notice the different addresses. There are still special cases for copying &PL_sv_undef, which I need to tackle. Since most constants created by ‘use constant’ have the PADMY flag on (since they reside in lexical variables inside constant.pm) and PADMY and PADTMP are exclusive, I have stop turning on PADTMP for constants. It is no longer necessary now, since before its purpose was to mark pad entries as being in use. That means many to-do tests pass.
* pad.c: Use &PL_sv_no for const pad namesFather Chrysostomos2013-07-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently &PL_sv_undef as a pad name can indicate either a free slot available for use by pad_alloc or a slot used by an op target (or, under ithreads, a constant or GV). Currently pad_alloc distinguishes between free slots and unnamed slots based on whether the value in the pad has PADMY or PADTMP set. If neither is set, then the slot is free. If either is set, the slot is in use. This makes it rather difficult to distinguish between constants stored in the pad (under ithreads) and targets. The latter need to be copied when referenced, to give the impression that a new scalar is being returned by an operator each time. (So \"$a" has to return a refer- ence to a new scalar each time, but \1 should return the same one.) Also, constants are shared between recursion levels. Currently, if the value is marked READONLY or is a shared hash key scalar, it is shared. But targets can also me shared hash keys, resulting in bugs. It also makes it impossible for the same constant to be shared by mul- tiple pad slots, as freeing one const op will turn off the PADTMP flag while the other slot still uses it, making the latter appear to be free. Hence a lot of copying occurs under ithreads. (Actually, that may not be true any more since 3b1c21fabed, as freed const ops swipe their constants from the pad. But right now, a lot of copying does still happen.) Also, XS modules may want to create const ops that return the same mutable SV each time. That is currently not possible without various workarounds including custom ops and references. (See <https://rt.perl.org/rt3/Ticket/Display.html?id=105906#txn-1075354>.) This commit changes pad_alloc and pad_free to use &PL_sv_no for con- stants and updates other code to keep all tests passing. Subsequent commits will actually use that information to fix bugs. This will probably break PadWalker, but I think it is an acceptable trade-off. The alternative would be to make PadnamePV forever more complex than necessary, by giving it a special case for &PL_sv_no and having it return NULL. I gave PadnameLEN a special case for &PL_sv_undef, so it may appear that I have simply shifted the complexity around. But if pad names stop being SVs, then this exception will simply disappear, since the global &PL_padname_undef will have 0 in its length field.
* op.c:S_fold_constants: Add assertionFather Chrysostomos2013-07-251-0/+1
| | | | | | | | | | | | | | This code correctly handles a value returned by a folded constant that is a target or a mortal. If it is neither, then it takes ownership of a reference count (with- out doing SvREFCNT_inc), so it ends up sharing a reference count with whatever owned it before. That is only safe to do with immortals, which is (afaict) the only other type of scalar that can get through this code, so it is actually correct. Changes elsewhere could easily break this, though, so add an assertion.
* op.c: Add op_folded to BASEOPNiels Thykier2013-07-191-4/+10
| | | | | | | | | Add a new member, op_folded, to BASEOP. It is replacement for OPpCONST_FOLDED (which can only be set on OP_CONST). At the moment OPpCONST_FOLDED remains, as it is exposed in B (e.g. B::Concise relies on it). Signed-off-by: Niels Thykier <niels@thykier.net>
* Stop using IV in pmop; remove workaroundFather Chrysostomos2013-07-061-13/+0
| | | | | | | | | | | See ticket #118055 for all the detail. On systems where IV is bigger than a pointer, the slab allocator messes things up because it only provides pointer alignment. If pmops have an IV field, we cannot allocate them via slab on such systems. Pmops actually don’t need an IV, just a PADOFFSET. So we can change them and remove the workaround. This is obviously not suitable for maint.
* op.c: White-space onlyKarl Williamson2013-07-041-10/+10
| | | | Outdent to correspond with removed block
* PATCH: [perl #114178] di/ds/ig exempt from warnings in void contextKarl Williamson2013-07-041-14/+1
|
* Terser fix to avoid warning about an empty body for Slab_to_rw().Nicholas Clark2013-07-021-4/+3
| | | | | | | Slab_to_rw() is only defined as a function with -DPERL_DEBUG_READONLY_OPS. This approach to silencing the warning feels more robust, because it ensures that Slab_to_rw() acts as a single statement whatever compile-time options are used.
* op.c: Suppress compiler warningFather Chrysostomos2013-06-281-0/+1
| | | | | | | | | | | Sorry, commit 08aff5359 was not quite ready and I pushed it too soon. The purpose of the if block that it removed was to suppress a warn- ing about an unused variable, but it was a very strange way of accom- plishing that. We have a much simpler way that takes only one line and expresses its intent clearly.
* op.c: Remove dummy code from const_sv_xsubFather Chrysostomos2013-06-281-8/+0
| | | | | | | This was added in commit 9cbac4c7 with no explanation. It has been #ifdeffed out since it was added. That commit was supposedly just for compiler warnings. I think this was something else the author was playing with that got combined in the same patch by mistake.
* op.c:cv_ckproto_len_flags: do null checks firstFather Chrysostomos2013-06-281-2/+2
| | | | | Checking local variables for nullness is faster than calling ckWARN_d, which involves a function call.
* Reinstate UTF8fFather Chrysostomos2013-06-281-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | This format string allows char*s to be interpolated with the utf8ness and length specified as well, avoiding the need to create extra SVs: Perl_croak(aTHX_ "Couldn't twiggle the twoggle in \"%"UTF8f"\"", UTF8fARG(is_utf8, len, s)); This is the second attempt. I screwed up in commits 1c8b67b38f0a5 and b3e714770ee1 because I didn’t really understand how varargs functions receive their arguments. They are like structs, in that different members can be different sizes. So therefore both ends--the caller and the called--*must* get the casts right, or the data will be corrupted. The main mistake I made was to use %u in the format for the first argument and then retrieve it as UV (a simple typo, I meant unsigned int or U32--I don’t remember). To be on the safe side, I added a UTF8fARG macro (after SVfARG), which (unlike SVfARG) takes three arguments and casts them explicitly, mak- ing it much harder to get this wrong at call sites.
* cv_ckproto should disregard spacesPeter Martini2013-06-271-41/+50
| | | | | | | This included some refactoring to break down the original large if block into smaller, more manageable chunks, although the only functional change was to pass the two string buffers through S_strip_spaces.
* Put all sort arguments in list contextFather Chrysostomos2013-06-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The arguments following the first were using the context the enclosing function was called in. sub context { warn qw[void scalar list][wantarray + defined wantarray ] } sub foo { sort +context, context; print "------\n"; } foo; $_ = foo; [foo]; __END__ Output: list at - line 1. void at - line 1. ------ list at - line 1. scalar at - line 1. ------ list at - line 1. list at - line 1. ------ Extend the list context to all arguments.
* Put sort arguments in lvalue contextFather Chrysostomos2013-06-261-1/+7
| | | | | | | | | | | | Since $a and $b are aliased to the actual scalars being sorted, and since they can be modified, the list of items needs to be in lvalue context, like the arguments to grep. Otherwise implementation details leak through, in that sort{$a=1} $_,... will modify $_, but sort{$a=1} $#_,... will fail to modify $#_. The way I have written the loop and if() condition (the if inside the loop) may seem odd and inefficient, but the next commit will take advantage of that.
* op.c:S_simplify_sort: remove redundant OPf_STACKED checkFather Chrysostomos2013-06-251-2/+0
| | | | | S_simplify_sort is only called from one spot and only when the OPf_STACKED flag is not set.
* op.c:ck_sort: Restore HINT_LOCALIZE_HH checkFather Chrysostomos2013-06-251-1/+2
| | | | | I remove this by mistake in commit 354dd559d99. It makes no difference to the behaviour. This check is just for efficiency.
View Lorry Controller Status