summaryrefslogtreecommitdiff
path: root/sv.c
Commit message (Collapse)AuthorAgeFilesLines
* Clarify docs for sv_usepvn_flagsFather Chrysostomos2011-12-041-1/+3
| | | | | Note that the string must be the start of a mallocked block of memory, and not a pointer to the middle of it.
* Remove SvTAINT from sv_sethekFather Chrysostomos2011-12-031-4/+0
| | | | | | | | | | | This was copied from sv_usepvn_flags in commit 58b643af9. It is unnecessary, and probably incorrect, as heks are not tainted. Why sv_sethek used sv_usepvn_flags to begin with I don’t know, but I imagine it was for brevity’s sake. This code was ultimately derived from newSVhek, which doesn’t use sv_usepvn_flags. Because of that, and because it is now far enough removed from sv_usepvn_flags, I have removed the comment referring to it.
* Stop calling sv_usepvn_flags from sv_sethekPeter Martini2011-12-031-1/+7
| | | | | | | | | | | | | | | sv_usepvn_flags assumes that ptr is at the head of a block of memory allocated by malloc. If perl's malloc is in use, the data structures malloc uses and the data allocated for perl are intermixed, and accounting done by malloced_size in sv_usepvn_flags will overwrite valid memory if its called on an address that is not the start of a malloced block. The actual work being accomplished by sv_usepvn_flags, and not undone immediately after by sv_sethek, is limited to 3 calls on the SV. Inlining those calls removes the dependency on malloc. This fixes perl #104034.
* Allow COW PVMGs to be tiedFather Chrysostomos2011-12-011-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This logic in sv_magic is wrong: if (SvREADONLY(sv)) { if ( /* its okay to attach magic to shared strings; the subsequent * upgrade to PVMG will unshare the string */ !(SvFAKE(sv) && SvTYPE(sv) < SVt_PVMG) && IN_PERL_RUNTIME && !PERL_MAGIC_TYPE_READONLY_ACCEPTABLE(how) ) { Perl_croak_no_modify(aTHX); } } There is nothing wrong with attaching magic to a shared string that will stay shared. Also, shared strings are not always < SVt_PVMG. Sometimes a PVMG or PVLV can end up with a shared string. In those cases, the logic above treats them as read-only, which they ain’t. The easiest example is a downgraded typeglob: $x = *foo; # now a PVGV undef $x ; # downgraded to PVMG $x = __PACKAGE__; # now a shared string (COW) tie $x, "main"; # bang! $x is considered read-only sub main::TIESCALAR{bless[]}
* Use SvOOK_onFather Chrysostomos2011-12-011-3/+2
| | | | | | Now that SvOOK_on has a usable definition (i.e., it leaves the NIOK flags alone), we can use it and remove the comments warning against it.
* sv.c: fix comment typo added by ce2077b184Father Chrysostomos2011-11-301-1/+1
|
* sv.c/find_uninit_var: Explain kid-scanning loop betterFather Chrysostomos2011-11-291-2/+7
| | | | | Hopefully this explanation will be clearer and will prevent clumsy individuals like me from introducing bugs like #103766.
* sv.c: typoFather Chrysostomos2011-11-291-1/+1
|
* sv.c: Turn a FIXME comment into an explanationFather Chrysostomos2011-11-271-3/+3
|
* ‘Inline’ S_sv_unglobFather Chrysostomos2011-11-241-1/+1
| | | | | S_sv_unglob is only called in one place, so inline it (but cheat, to preserve blame history).
* Make COW-clobbering fasterFather Chrysostomos2011-11-241-3/+8
| | | | | | | | | | | | | | | | | | | | | | | There is this special SV_COW_DROP_PV flag that gets passed to sv_force_normal_flags to signal that the SV is about to be clobbered, so there is no point in allocating a new PV. But this flag was not actually being used, until the previous commit commandeered it for globs (despite the name). Now it actually does what it says. Before and after: $ time ./perl -e '$x = __PACKAGE__, undef $x for 1..8000000' real 0m5.758s user 0m5.740s sys 0m0.008s $ time ./perl -e '$x = __PACKAGE__, undef $x for 1..8000000' real 0m3.290s user 0m3.282s sys 0m0.006s
* Make assignment over glob copies much fasterFather Chrysostomos2011-11-241-4/+6
| | | | | | | | | | | | | | | | | | | sv_force_normal is passed the SV_COW_DROP_PV flag if the scalar is about to be written over. That flag is not currently used. We can speed up assignment over fake GVs a lot by taking advantage of the flag. Before and after: $ time ./perl -e '$x = *foo, undef $x for 1..2000000' real 0m4.264s user 0m4.248s sys 0m0.007s $ time ./perl -e '$x = *foo, undef $x for 1..2000000' real 0m1.820s user 0m1.812s sys 0m0.005s
* sysread should not ignore magic on its bufferFather Chrysostomos2011-11-241-1/+2
| | | | | | sysread uses SvPV_force, which has a bug in it. Even if the SV_GMAGIC flag is passed to sv_pvn_force_flags (which SvPV_force does), it ignores magic in any typeglob argument.
* printf "%vd", "version" should not SEGVFather Chrysostomos2011-11-231-1/+1
| | | | See perl #102586.
* sv.c/sv_insert_flags: typoFather Chrysostomos2011-11-221-1/+2
|
* amagic_deref_call does not necessitate SPAGAINFather Chrysostomos2011-11-221-2/+0
| | | | | As amagic_deref_call pushes a new stack, PL_stack_sp will always have the same value before and after, so SPAGAIN is unnecessary.
* [perl #103766] Wrong $" warning in perl 5.14Father Chrysostomos2011-11-221-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This code: "@{[ $x ]}" was producing the warning: Use of uninitialized value $" in join or string at -e line 1. erroneously, as of commit 6d1f0892c. Commit 6d1f0892c was meant to fix bug #72090, which caused the varia- ble to be mentioned even for the > warning in this instance: $ ./perl -we '$a = @$a > 0' Use of uninitialized value $a in array dereference at -e line 1. Use of uninitialized value $a in numeric gt (>) at -e line 1. The fix for #72090 was wrong, because the loop that it modified loops through the kid ops, finding out how many candidates there are. If there is only one candidate left, it is used. Skipping ops that could be responsible for the undefined value just because we don’t want to mention their variables is the wrong approach, at least in that loop, as the blame will fall on whatever other op is left if there is only one. There is code further up to deal with the OP_RV2[AH]V case, that des- cends explicitly into the child ops. This commit tweaks that code to descend only for the top-level op, to allow @{ $x } to warn still about an uninitialised value used in array dereference. Where @{...} is an operand to the operator that is emitting the warning, we don’t descend. That is how #72090 should have been fixed to begin with, as it has no odd side effects. This bug (#103766) affects any other cases where there are two oper- ands and one is @{...} or %{...}: $ perl5.15.4 -e 'use warnings "uninitialized"; $y = 6; $y + @{ $x }' Use of uninitialized value $x in array dereference at -e line 1. Use of uninitialized value $y in addition (+) at -e line 1. $y is obviously not responsible there.
* sv.c: newSVpvf( → Perl_newSVpvf(aTHX_Father Chrysostomos2011-11-211-1/+1
| | | | | I don’t know why this is necessary, but there are some strange #defines surrounding this function.
* Put sub redef warnings in one placeFather Chrysostomos2011-11-211-38/+16
| | | | | | | | | | The logic surrounding subroutine redefinition warnings (to warn or not to warn?) was in three places. Over time, they drifted apart, to the point that newXS was following completely different rules. It was only warning for redefinition of functions in the autouse namespace. Recent commits have brought it into conformity with the other redefi- nition warnings. Obviously it’s about time we put it in one function.
* Make constant sub redef warnings obey scopeFather Chrysostomos2011-11-211-0/+1
| | | | | | | | | | | In perldiag, this is listed as (S), which means that outside of any use/no warnings scope it always warns, regardless of $^W. But this warning was ignoring use/no warnings, too. There were actually tests for this oddity, but I think those were added by mistake, or this was just not thought through. I cannot see how this is not a bug.
* Don’t call an early-returning destructorFather Chrysostomos2011-11-211-2/+10
| | | | | | | | | | | | | | | | This speeds things up 2.8 times in my naïve benchmarks. This applies to code like: use constant DEBUG => 1; DESTROY { return unless DEBUG; ... } which gets optimised down to: DESTROY { return; ... } Adding such a destructor will now have almost no impact on speed in production.
* Restore autouse’s exemption from redef warningsFather Chrysostomos2011-11-211-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This also restores the subroutine redefinition warning for newly-cre- ated XSUBs outside the autouse package. See below. This commit added the exemption to fix a known bug, that loading a module and importing from it would cause a redefinition warning if there were an autouse stub: perl-5.004_03-1092-g2f34f9d commit 2f34f9d4825ac9262ece854fc4c50479f4838ff8 Author: Ilya Zakharevich <ilya@math.berkeley.edu> Date: Mon Mar 2 16:36:02 1998 -0500 Make autouse -w-safe p4raw-id: //depot/perl@781 The subroutine redefinition warning occurs in three places. This commit removed the autouse exemption from two of them. I can’t see how it wasn’t a mistake, as <5104D4DBC598D211B5FE0000F8FE7EB202D49EE9@mbtlipnt02.btlabs.bt.co.uk> (the apparent source of the patch, makes no mention of it: perl-5.005_02-2920-ge476b1b commit e476b1b5c29f354cf8dad61a9fc6d855bdfb5b7d Author: Gurusamy Sarathy <gsar@cpan.org> Date: Sun Feb 20 22:58:09 2000 +0000 lexical warnings update, ability to inspect bitmask in calling scope, among other things (from Paul Marquess) p4raw-id: //depot/perl@5170 This commit refactored things to remove some compiler warnings, but in doing so reversed the logic of the condition, causing redefini- tion warnings for newly-created XSUBs to apply only to subs from the autouse package: perl-5.8.0-5131-g66a1b24 commit 66a1b24beb76ea873ad4caa57ee3ab9df945afbf Author: Andy Lester <andy@petdance.com> Date: Mon Jun 6 05:11:07 2005 -0500 Random cleanups #47 Message-ID: <20050606151107.GC7022@petdance.com> p4raw-id: //depot/perl@24735 I’ve basically reinstated the changes in 2f34f9d4, but with tests this time. It may not make sense for autouse to be exempt for newATTRSUB and newXS, but keeping the logic surrounding the warning as close as possible to being the same could allow future refactorings to merge them.
* sv.c: I missed a dotFather Chrysostomos2011-11-211-1/+1
|
* sort does not call get-magic after dereffingFather Chrysostomos2011-11-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sort $f @list accepts a globref for $f, and probably has since Perl 5.000, even if it was by mistake that it ever worked. It doesn’t respect get-magic, however: $ perl -le 'sub s { $b <=> $a }; $f = \*s; print sort $f 1,2,3' 321 $ ./perl -Ilib -le ' sub TIESCALAR{bless[]} sub FETCH {*s} sub s { $b <=> $a }; tie $f, ""; $g = \$f; print sort $g 1,2,3' Not a subroutine reference at -e line 1. Interestingly, this commit added support for sort $coderef @foo: commit 7a4920e67d1e2d67a4397a908141c6608866ebb0 Author: Graham Barr <gbarr@pobox.com> Date: Fri Nov 27 05:16:50 1998 +0000 integrate change#2246 from mainline, while still allowing C<sort $globref @foo> allow C<sort $coderef @foo> p4raw-link: @2246 on //depot/perl: c6e96bcb406bc8b8d8610606459ff606ad6883aa p4raw-id: //depot/maint-5.005/perl@2315 p4raw-integrated: from //depot/perl@2314 'merge in' t/op/sort.t (@1760..) If I’m reading this code correctly, it did so by nulling out whatever op used to come after the pushmark (now it is always a null): $ perl -MO=Concise -e 'sort $fo @fo'8 <@> leave[1 ref] vKP/REFC ->(end) 1 <0> enter ->2 2 <;> nextstate(main 1 -e:1) v:{ ->3 7 <@> sort vKS ->8 3 <0> pushmark s ->4 - <1> null K/1 ->5 <--- Lo! - <1> ex-rv2sv sK/1 ->- 4 <#> gvsv[*fo] s ->5 6 <1> rv2av[t3] lK/1 ->7 5 <#> gv[*fo] s ->6 -e syntax OK To preserve the globref support (which the nulled op was providing before), it added it to sv_2cv, which was the wrong place if you ask me. Now it means that &{\*_} works, in addition to &{*_}. Other deref ops don’t have this property. Bug? Maybe. But we can just pretend it’s a feature and live with it. In any case, extracting the entry of a typeglob without calling get- magic on it first doesn’t seem right.
* Document sv_2io’s invocation of magicFather Chrysostomos2011-11-191-0/+3
|
* Call FETCH once on handle passed as 3rd arg to open()Father Chrysostomos2011-11-191-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | When open() has three arguments and the second ends with & the third argument is treated as a handle. In some cases get-magic was being skipped; in others, it was being called three times. This commit fixes it by modifying sv_2io. In 5.8.x (before commit 7a5fd60d4), sv_2io did not call get-magic at all except when croaking ("Bad filehandle: %"SVf). In 5.10.0 (after commit 7a5fd60d4), it started calling get-magic only if the sv was neither a glob, a reference, or undef. So it has never been reliable in its invocation of get-magic. sv_2io now consistently skips get-magic on the sv passed in directly to it (open(), the only caller in the core, has already called get- magic before passing it in). It now calls get-magic on SvRV(sv) if what is passed in is a reference, so open(fh, ">&", \$tied) will work. Interestingly, open supports multiple levels of references: \\\\\\\\\\\\open+f,">&",\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\\\\\\*STDOUT;print{f}"Just another Perl hacker,\n",.\\\\\\\y\\\
* sv.c: More consistent use of spaces after dotsFather Chrysostomos2011-11-191-72/+78
| | | | in apidocs, plus other tweaks
* Correct sv_catsv_flags docsFather Chrysostomos2011-11-191-1/+3
| | | | Get-magic is only called on ssv. SV_SMAGIC is accepted, too.
* Correct sv_catpv_flags docsFather Chrysostomos2011-11-191-2/+2
| | | | SV_SMAGIC, not SV_GMAGIC.
* Correct sv_catpvn_flags docsFather Chrysostomos2011-11-191-2/+3
| | | | It respects SV_SMAGIC flag, not SV_GMAGIC (which it ignores).
* Mention implicit $_ in y///r uninit warningFather Chrysostomos2011-11-191-0/+1
| | | | This brings it into conformity with y without the /r.
* Mention the variable name in the new length warningsFather Chrysostomos2011-11-181-2/+2
|
* Tweaks to find_uninit_var docsFather Chrysostomos2011-11-181-3/+3
| | | | | | • Typos • Double space after fullstop, as that is how nroff renders a fullstop at the end of a line in mid-paragraph.
* Unused variable in in sv_eqBrian Fraser2011-11-171-3/+0
|
* expunge gratuitous Unicode punctuation in commentsZefram2011-11-161-3/+3
|
* Stop toggling the FAKE flag for stringified GVsFather Chrysostomos2011-11-061-18/+0
| | | | | | | | | | | | | | Back in the old days, when GVs had magic attached to them, get-magic used to stringify the glob and assign the string to the PV field. It was triggered in mg.c like this: gv_efullname3(sv,((GV*)sv), "*"); Because sv was both the glob being read *and* the string being assigned to, the stringification would call set-magic on the glob and flatten the glob into a string. Or something like that. That is not necessary any more.
* [perl #96326] *{$io} should not be semi-definedFather Chrysostomos2011-11-061-10/+4
| | | | | | | | | | | | | | | | | | | | | gv_efullname4 produces undef if the GV points to no stash, instead of using __ANON__, as it does when the stash has no name. Instead of going through hoops to try and work around it elsewhere, fix gv_efullname4. This means that $x = *$io; $x .= "whate’er"; no longer produces an uninitialized warning. (The warning was rather strange, as defined() returned true.) This commit also gives the glob the name $__ANONIO__ (yes, with a dol- lar sign). It may seem a little strange, but there is precedent in other autovivified globs, such as those open() produces when it cannot determine the variable name (e.g, open $t->{fh}).
* Fill out sv_upgrade docsFather Chrysostomos2011-11-041-1/+4
| | | | See commit 5a0c33f0f.
* Use SvUPGRADE, not sv_upgrade, in sv_sethekFather Chrysostomos2011-11-041-1/+1
| | | | | | | | | | | | | | This was causing some interesting HTML::Element failures, which were only triggered by HTML::DOM’s test suite. ref’s TARG can become tainted if another op in the same statement turns on tainting for the rest of the statement, so it becomes a PVMG. The next call to the same ref will try to sv_upgrade it to a PV (which is lower). Only the macro version, SvUPGRADE, checks whether the upgrade is needed. ref only calls sv_sethek when it has a blessed object for its argu- ment, hence the strange-looking test.
* Fix CORE::globFather Chrysostomos2011-10-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This commit makes CORE::glob bypassing glob overrides. A side effect of the fix is that, with the default glob implementa- tion, undefining *CORE::GLOBAL::glob no longer results in an ‘unde- fined subroutine’ error. Another side effect is that compilation of a glob op no longer assumes that the loading of File::Glob will create the *CORE::GLOB::glob type- glob. ‘++$INC{"File/Glob.pm"}; sub File::Glob::csh_glob; eval '<*>';’ used to crash. This is accomplished using a mechanism similar to lock() and threads::shared. There is a new PL_globhook interpreter varia- ble that pp_glob calls when there is no override present. Thus, File::Glob (which is supposed to be transparent, as it *is* the built-in implementation) no longer interferes with the user mechanism for overriding glob. This removes one tier from the five or so hacks that constitute glob’s implementation, and which work together to make it one of the buggiest and most inconsistent areas of Perl.
* [perl #101486] Make PL_curstash refcountedFather Chrysostomos2011-10-221-1/+1
| | | | | | | | | | This stops PL_curstash from pointing to a freed-and-reused scalar in cases like ‘package Foo; BEGIN {*Foo:: = *Bar::}’. In such cases, another BEGIN block, or any subroutine definition, would cause a crash. Now it just happily proceeds. newATTRSUB and newXS have been modified not to call mro_method_changed_in in such cases, as it doesn’t make sense.
* [perl #101738] Make sv_sethek set the UTF8 flag correctlyFather Chrysostomos2011-10-201-0/+2
| | | | | | | | | | | | | | | It was only ever turning it on, and not turning it off if the sv hap- pened to have it on from its previous use. This caused ref() (which uses sv_sethek(TARG,...)) to return a shared scalar with the UTF8 flag on, even if it was supposed to be off. For shared scalars, the UTF8 flag on ASCII strings does make a differ- ence. The pv *and* the flags are used in hash lookup, for speed. So a scalar returned by ref() with the UTF8 flag on by mistake would not work in hash lookups. exists $classes{ref $foo} would return false, even if there were an entry for that class.
* Stop uninit sort warnings from crashingFather Chrysostomos2011-10-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | Commit d4c6760a made the warning in cases like this mention the sort operator: $ ./miniperl -we '()=sort { undef } 1,2' Use of uninitialized value [in sort] at -e line 1. It did so by setting PL_op during the SvIV(retval of sort block). But sv.c:S_find_uninit_var, called by report_uninit, tries to access the targets of some ops, which are in PL_curpad on threaded builds. In the case of a sort sub (rather than an inlined block), PL_curpad con- tained whatever was left over from the sort block (I presume, but have not confirmed; in any case what is in PL_curpad is bad), causing find_uninit_var to crash. This commit sets PL_curpad to null and puts a check for it in report_uninit. It did not crash in debugging threaded builds, but that was probably luck (even though I don’t believe in it).
* Call get-magic once for .. in list contextFather Chrysostomos2011-10-131-6/+4
| | | | | | | | In addition to using _nomg calls in pp_flop, I had to modify looks_like_number, which was clearly buggy: it was ignoring get-magic completely, *except* in the case of SvPOKp. But checking SvPOKp before calling magic does not make sense, as it may change during the magic call.
* SSize_t, not IV, is a signed STRLENChip Salzenberg2011-10-111-1/+1
|
* Make sv_set[ps]v(cv...) set prototypeFather Chrysostomos2011-10-111-0/+3
| | | | | | | | | | | | | | | | | | | | The SvPVX slot of a CV is used both for the prototype and for the sub name passed to an XS AUTOLOAD sub. It used to be that such AUTOLOADing would clobber the prototype. Commit 8fa6a4095 made the two uses of SvPVX try to play along nicely with each other, so the prototype comes after the sub name if both need to be present. It added the CvPROTO macro to account for that. Some CPAN modules expect to be able to set the prototype with sv_set[ps]v. So this commit makes that work as expected, by turn- ing off the flag that says the prototype comes after the auto- loaded sub name. Anyone using Scalar::Util::set_prototype to work around the proto- type-clobbering bug can now continue to do so, without triggering a new bug.
* under DEBUGGING, minimize the sentinels written in sv_chop, to avoid substr ↵Chip Salzenberg2011-10-101-12/+14
| | | | slowdown
* tweak sv_chop podChip Salzenberg2011-10-101-0/+5
|
* I32 may not be big enough for string insert lengthChip Salzenberg2011-10-101-1/+1
|
* Fix cv-to-gv assignment to use CvPROTOFather Chrysostomos2011-10-101-2/+2
| | | | | | | | | | The SvPVX field of a XS AUTOLOAD sub can contain both the prototype and the name of an AUTOLOADed sub. The CvPROTO macro knows where in the buffer to find the prototype. All code that reads the prototype should use it. When I introduced it with commit 8fa6a4095, one code path was missed: *regular_prototyped_sub = \&prototyped_XS_AUTOLOAD was using the sub name of the rhs, instead of the prototype, in the prototype check.
View Lorry Controller Status