summaryrefslogtreecommitdiff
path: root/sv.h
Commit message (Collapse)AuthorAgeFilesLines
* SvGROW should un-cow under PERL_OLD_COPY_ON_WRITEFather Chrysostomos2014-01-161-1/+1
| | | | | | | Otherwise pp_uc (and presumably other pieces of code) will end up mod- ifying shared buffers. Brought to you by PERL_DEBUG_READONLY_COW.
* perlapi: Consistent spaces after dotsFather Chrysostomos2013-12-291-8/+11
| | | | plus some typo fixes. I probably changed some things in perlintern, too.
* Revert "make perl core quiet under -Wfloat-equal"David Mitchell2013-11-161-1/+1
| | | | | | | | | | | A suggested way of avoiding the the warning on nv1 != nv2 by replacing it with (nv1 < nv2 || nv1 > nv2), has too many issues with NaN. [perl #120538]. I haven't found any other way of selectively disabling the warning, so for now I'm just reverting the whole commit. This reverts commit c279c4550ce59702722d0921739b1a1b92701b0d.
* make perl core quiet under -Wfloat-equalDavid Mitchell2013-11-091-1/+1
| | | | | | | | | | | | | | | | | | | | The gcc option -Wfloat-equal warns when two floating-point numbers are directly compared for equality or inequality, the idea being that this is usually a logic error, and that you should be checking that the values are instead very near to each other. perl on the other hand has lots of reasons to do a direct comparison. Add two macros, NV_eq_nowarn(a,b) and NV_eq_nowarn(a,b) that do the same as (a == b) and (a != b), but without the warnings. They achieve this by instead doing (a < b) || ( a > b). Under gcc at least, this is optimised into the same code as the direct comparison. The are three places that I've left untouched, because they are handling NaNs, and that gets a bit tricky. In particular (nv != nv) is a test for a NaN, and replacing it with (< || >) creates signalling NaNs (whereas == and != create quiet NaNs)
* correct POD for SvIsCOW, it returns a U32Daniel Dragan2013-10-231-2/+2
|
* sv.h: Make BmUSEFUL the same type on debug/non-debug buildsFather Chrysostomos2013-09-151-1/+1
| | | | | 408dc2ec1c7 made in an IV (signed) on debugging builds but a UV (unsigned) on regular builds.
* Move BmUSEFUL to the IV slot from the NV slot, simplifying union _xnvu.Nicholas Clark2013-09-131-5/+4
| | | | | This change is made possible by commit 8922e4382e9c1488 (June 2013), which eliminated BmPREVIOUS, which had been using the IV slot.
* [perl #119481] Check SvVALID for !SvSCREAM, skip PADReini Urban2013-09-031-4/+7
| | | | | | | SVpad_NAME = SVp_SCREAM|SVpbm_VALID Subsequently OUR, TYPED and STATE pads all have SVp_SCREAM set. SVpad_NAME shares the same bit with SVpbm_VALID, so avoid checking PADs for SVpbm_VALID.
* Stop pos() from being confused by changing utf8nessFather Chrysostomos2013-08-251-2/+1
| | | | | | | | | | | | | | | | | | | | | | | The value of pos() is stored as a byte offset. If it is stored on a tied variable or a reference (or glob), then the stringification could change, resulting in pos() now pointing to a different character off- set or pointing to the middle of a character: $ ./perl -Ilib -le '$x = bless [], chr 256; pos $x=1; bless $x, a; print pos $x' 2 $ ./perl -Ilib -le '$x = bless [], chr 256; pos $x=1; bless $x, "\x{1000}"; print pos $x' Malformed UTF-8 character (unexpected end of string) in match position at -e line 1. 0 So pos() should be stored as a character offset. The regular expression engine expects byte offsets always, so allow it to store bytes when possible (a pure non-magical string) but use char- acters otherwise. This does result in more complexity than I should like, but the alter- native (always storing a character offset) would slow down regular expressions, which is a big no-no.
* [perl #118691] Allow defelem magic with neg indicesFather Chrysostomos2013-08-211-1/+7
| | | | | | | | | | | | | | | | | | | | | | When a nonexistent array element is passed to a subroutine, a special ‘deferred element’ scalar (implemented using something called defelem magic) is passed to the subroutine instead, which delegates to the array element. This allows some_benign_function($array[$nonexistent]) to avoid autovivifying unnecessarily. Whether this magic would be triggered was based on whether the element was within the range 0..$#array. Since arrays can contain nonexistent elements before $#array, this logic is incorrect. It also makes sense to allow $array[$neg] where the negative number points before the beginning of the array to create a deferred element and only croak if it is assigned to. This commit fixes the logic for when deferred elements are created and implements these deferred negative elements. Since we have to be able to store negative values in xlv_targoff, it is convenient to make it a union (with two types--signed and unsigned) and use LvSTARGOFF for defelem array indices.
* sv.h: Add comment about gv_check and SvIsCOWFather Chrysostomos2013-08-061-0/+1
| | | | | So that future refactorings don’t make use of 0x00010000 on hashes without modifying gv_check to account.
* Skip trailing constants when searching padsFather Chrysostomos2013-07-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under ithreads, constants and GVs are stored in the pad. When names are looked up up in a pad, the search begins at the end and works its way toward the beginning, so that an $x declared later masks one declared earlier. If there are many constants at the end of the pad, which can happen for generated code such as lib/unicore/TestProp.pl (which has about 100,000 lines and over 500,000 pad entries for constants at the end of the file scope’s pad), it can take a long time to search through them all. Before commit 325e1816, constants used &PL_sv_undef ‘names’. Since that is the default value for array elements (when viewed directly through AvARRAY, rather than av_fetch), the pad allocation code did not even bother storing the ‘name’ for these. So the name pad (aka padnamelist) was not extended, leaving just 10 entries or so in the case of lib/unicore/TestProp.pl. Commit 325e1816 make pad constants have &PL_sv_no names, so the name pad would be implicitly extended as a result of storing &PL_sv_no, causing a huge slowdown in t/re/uniprops.t (which runs lib/unicore/TestProp.pl) under threaded builds. Now, normally the name pad *does* get extended to match the pad, in pad_tidy, but that is skipped for string eval (and required file scope, of course). Hence, wrapping the contents of lib/unicore/TestProp.pl in a sub or adding ‘my $x’ to end of it will cause the same slowdown before 325e1816. lib/unicore/TestProp.pl just happened to be written (ok, generated) in such a way that it ended up with a small name pad. This commit fixes things to make them as fast as before by recording the index of the last named variable in the pad. Anything following that is disregarded in pad lookup and search begins with the last named variable. (This actually does make things faster before for subs with many trailing constants in the pad.) This is not a complete fix. Adding ‘my $x’ to the end of a large file like lib/unicore/TestProp.pl will make it just as slow again. Ultimately we need another algorithm, such as a binary search.
* sv.h: Comments added/typo fixed.Karl Williamson2013-07-191-1/+8
|
* Remove redundant field from inversion listsKarl Williamson2013-07-161-1/+0
| | | | | | | The number of elements in an inversion list is a simple calculation based on SvCUR(). Prior to this patch there was a field that contained that number directly, and the two values diverged, causing a bug. A single value can't get out-of-sync with itself.
* Reinstate "Use new Svt_INVLIST for inversion lists."Karl Williamson2013-07-161-0/+8
| | | | | | | | | | | This reverts commit 2e0b8fbeab3502bee36f25825c3cdd0d075c4fd3, which reverted e0ce103ae532f9576f54a5938a24d1ee98dfb928, thus reinstating the latter commit. It turns out that the error being chased down was not due to this commit. Its original message was: This converts inversion lists to use their own scalar type.
* Reinstate "Create SVt_INVLIST"Karl Williamson2013-07-161-6/+14
| | | | | | | | | | | | | | | | | This reverts commit 49cf1d6641a6dfd301302f616e4f25595dcc65d4, which reverted e045dbedc7da04e20cc8cfccec8a2e3ccc62cc8b, thus reinstating the latter commit. It turns out that the error being chased down was not due to this commit. Its original message was: This reshuffles the svtype enum to remove the dummy slot created in a previous commit, and add the new SVt_INVLIST type in its proper order. It still is unused, but since it is an extension of SVt_PV, it must be greater than that type's enum value. Since it can't be upgraded to any other PV type, it comes right after SVt_PV. Affected tables in the core are updated.
* Fix typo in docs for SvPV: ") => >"Brian Gottreu2013-07-101-1/+1
|
* Revert "Create SVt_INVLIST"Karl Williamson2013-07-041-14/+6
| | | | | | | | This reverts commit e045dbedc7da04e20cc8cfccec8a2e3ccc62cc8b. Blead won't compile with address sanitizer; commit 7cb47964955167736b2923b008cc8023a9b035e8 reverting an earlier commit failed to fix that. I'm trying two more reversions to get it back working. This is one of those
* Revert "Use new Svt_INVLIST for inversion lists."Karl Williamson2013-07-041-8/+0
| | | | | | This reverts commit e0ce103ae532f9576f54a5938a24d1ee98dfb928. This commit is failing compilations with address sanitizer, and we don't know why. This reverts it while we work that out.
* Use new Svt_INVLIST for inversion lists.Karl Williamson2013-07-031-0/+8
| | | | This converts inversion lists to use their own scalar type.
* Create SVt_INVLISTKarl Williamson2013-07-031-6/+14
| | | | | | | | | | This reshuffles the svtype enum to remove the dummy slot created in a previous commit, and add the new SVt_INVLIST type in its proper order. It still is unused, but since it is an extension of SVt_PV, it must be greater than that type's enum value. Since it can't be upgraded to any other PV type, it comes right after SVt_PV. Affected tables in the core are updated.
* SV_CONST(name) and PL_sv_constsRuslan Zakirov2013-06-301-0/+48
| | | | | | | | | SV_CONST(XXX) returns SV* that contains "XXX" string. SVs are built on demand and stored in interp's structure for re-use. All SVs have precomputed hash value. Creates SVs on demand, we don't want 35 SV created during compile time or cloned during thread creation.
* sv.h: Correct assertion in BmUSEFULFather Chrysostomos2013-06-221-1/+1
| | | | | BmUSEFUL uses the NV slot, not the IV slot. So asserting that it is not IOK is not all that useful.
* Remove BmRARE and BmPREVIOUSFather Chrysostomos2013-06-211-20/+8
| | | | | These were only used by the study code, which was disabled in 5.16.0 and removed shortly thereafter.
* Upgrade cv_flags_t from 16 to 32 bits.Peter Martini2013-06-181-1/+1
| | | | | | Its main use is in a struct otherwise filled with pointers, which means on 32-bit architectures its almost certainly taking up 32 bits anyway.
* [perl #118159] Make PVs take precedence in SvTRUEFather Chrysostomos2013-05-261-3/+4
| | | | | | | | | | | | Commit 4bac9ae4 (probably inadvertently) changed SvTRUE to treat an SV with any of PVX, IVX or NVX having a true value as true. Traditionally, truth was based solely on stringification. The examina- tion of the SvIVX and SvNVX slots was for those cases where there was no string already and it could be deduced from IVX or NVX whether it would stringify as "0" or no (bugs with -0 aside). This changes things back to the way they have ‘always’ been.
* Remove core references to SVt_BINDKarl Williamson2013-05-181-2/+1
| | | | | | This scalar type was unused. This is the first step in using the slot freed up for another purpose. The slot is now occupied by a temporary placeholder named SVt_DUMMY.
* further tweak SvPV() docsDavid Mitchell2013-05-091-5/+7
| | | | Make it clear that a different pointer may be returned each time.
* clarify SvPV* and SvPV_force* docsDavid Mitchell2013-05-091-9/+18
| | | | | | | | | | See RT #116407. Make it clear that SvPV(sv) does not always equal SvPVX(sv), and to use SvPV_force() if necessary. Also, clarify that SvPV_force() will destroy any non-string content like a reference. Then, make the other SvPV* descriptions in general refer back to SvPV() or SvPV_force(), so that people will spot these added caveats.
* better POD for SvPVX, pre-5.9.3 PerlsDaniel Dragan2013-03-061-1/+2
| | | | | | | PV/char * was moved to SV head in commit 7b2c381cf3 . Prior to this, PV was in SV body, and sv_any can be NULL, so accessing SvPVX without checking type on old Perls was a SEGV. Make a note of this so others don't find out the hard way.
* Remove the check for SVt_BIND from SvOK().Nicholas Clark2013-02-201-5/+1
| | | | | | | | | | | The original plan to use SVt_BIND to implement read-only aliases to read-write values is unlikely to happen. More importantly, it's not going to happen within a maint branch, so there's no reason to have the code "just in case" it does. The code can easily be re-instated in blead if it is needed in future. Nothing on CPAN is relying on this code. (Almost no code on CPAN even references SVt_BIND.) This effectively reverts part of commit 1cb9cd5016282146 from Dec 2006.
* perlapi: Fix SvIOK_UV, SvUOK descriptionsKarl Williamson2013-01-231-4/+6
| | | | | | | | Commit b630937b8bf49e835d8976fc1036e68c79585b04 changed the text of these two macros to how they currently work, but we don't want to be tied to this behavior in the future. New wording suggested by Darin McBride
* include SvREADONLY() in SvIMMORTAL() testDavid Mitchell2013-01-121-1/+1
| | | | | | | | | | | | | | | | SvIMMORTAL() is currently defined as ((sv)==&PL_sv_undef || (sv)==&PL_sv_yes || (sv)==&PL_sv_no || (sv)==&PL_sv_placeholder) Which is relatively slow. Some places do this: if (SvREADONLY(sv) && SvIMMORTAL(sv)) ... which quickly rejects most times. This commit simply moves the SvREADONLY test into the SvIMMORTAL macro so that *all* uses benefit from this speedup.
* Fix SvREFCNT_dec doc typoSteven Schubiger2013-01-041-1/+1
|
* Remove redundant NULL checks.Eric Brine2013-01-031-1/+1
| | | | It's safe to pass NULLs to SvREFCNT_dec.
* perlapi: Fix misstatementKarl Williamson2012-12-241-2/+4
| | | | | According to the comments for Perl_sv_setuv(), for performance reasons, a UV that fits in an IV is stored as an IV.
* perlapi: Fix typosKarl Williamson2012-12-241-2/+2
|
* perlapi: Clarify return value of SvREFCNT_inc()Karl Williamson2012-12-221-1/+1
|
* test the resetting of refcnt for immortalsDavid Mitchell2012-12-181-0/+7
| | | | | | | | PL_sv_undef etc get given a very high ref count, which if it ever reaches zero, is set back to a high value. On debugging builds, use a lower value (1000) so that the resetting code gets exercised occasionally. Also, replace literal (~(U32)0)/2 with the constant SvREFCNT_IMMORTAL.
* further fix to SvUPGRADEDavid Mitchell2012-12-141-1/+3
| | | | | | | | | | | | | | | | | | The change to SvUPGRADE introduced by 463ea2290a54e a few commits ago to silence a warning with clang, broke g++ builds instead. Here's a second attempt to keep everyone happy. Basically it avoids warnings from all of gcc, g++ and clang for the two constructs SvUPGRADE(...); (void)SvUPGRADE(...); But still breaks if (!SvUPGRADE(...) { croak(...); } which I don't care about.
* make SvUPGRADE() a statement.David Mitchell2012-12-141-1/+2
| | | | | | | | | | | | | | | | | | | | To guote the perldelta entry: SvUPGRADE() is no longer an expression. Originally this macro (and its underlying function, sv_upgrade()) were documented as boolean, although in reality they always croaked on error and never returned false. In 2005 the documentation was updated to specify a void return value, but SvUPGRADE() was left always returning 1 for backwards compatibility. This has now been removed, and SvUPGRADE() is now a statement with no return value. So this is now a syntax error: if (!SvUPGRADE(sv)) { croak(...); } If you have code like that, simply replace it with SvUPGRADE(sv);
* better POD for mg_get and SvGROWDaniel Dragan2012-12-111-1/+2
| | | | | | | | | | | SvGROW unconditionally derefs SvANY to check SvLEN. A crash occurs if the sv is SVt_NULL. Also mg_get uses SvMAGIC which also has the same problem. Rather than having people finding these properties out by trial and error, document them. There is no sense in adding type checks since these 2 calls have been had sv type restrictions since probably day 1 and for performance reason. Anyone who hit the restrictions would have either fixed their code immediately, or abandoned using XS. I observed someone abandoning XS in the field over these undocumented restrictions.
* sv.h: Warning about cows in SvPV_set apidocsFather Chrysostomos2012-12-051-1/+6
|
* add SvREFCNT_dec_NN()David Mitchell2012-12-041-0/+6
| | | | | | | | | Like SvREFCNT_dec(), but skips the not null check, making code potentially smaller and faster. Also as proof of concept, updates the SvREFCNT_dec's in scope.c where it's obvious the value can't be NULL. There are still 500+ uses in the perl core that need evaluating!
* Allow COW with magical and blessed scalars (among others)Father Chrysostomos2012-11-271-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under PERL_NEW_COPY_ON_WRITE (and I suspect under PERL_OLD_COPY_ON_WRITE, too, but have not confirmed) it is harmless to do copy-on-write with a magical or blessed scalar. Also, under PERL_NEW_COPY_ON_WRITE, it is safe to do copy-on-write with scalars that have numbers in them as well as strings (though not under PERL_OLD_COPY_ON_WRITE). So redefine CAN_COW_MASK under PERL_NEW_COPY_ON_WRITE to be less restrictive. We still can’t do it when the SvOOK hack is in place, and I don’t feel comfortable doing it with regexps, even if it could be proven feasible (regexps are SVf_FAKE, so that covers them). Anything SvROK cannot be SvPOK, so obviously we can’t COW with that, but I left SVf_ROK in for good measure. This change to CAN_COW_MASK affects whether non-cow scalars will be turned into cows in sv_setsv_flags. It is already possible for exist- ing cows to become magical, blessed or numeric elsewhere. Also, we don’t need to check the flags on the lhs in sv_setsv_flags, except for SVf_BREAK. This is similar to ecd5fa70f3, but applies to another branch just below it. pp_subst needs a little bit of adjustment, as it is not expecting a vstring to turn into a cow.
* Min string length for COWFather Chrysostomos2012-11-271-0/+6
| | | | | | | | | | | | | | | | | | | | | We have two separate length thresholds for when copy-on-write kicks in, one for when a buffer would have had to be (re)allocated (SV_COW_THRESHOLD) and another for when there is already a large enough buffer available (SV_COWBUF_THRESHOLD). Benchmarking against mktables and against Test.Simple’s test suite (see JS::Test::Simple on CPAN) run with WWW::Scripter and JE shows that 0/1250 is the best combination, at least on 32-bit darwin. Apparently, copying into an existing buffer is much faster than the bookkeeping overhead of sv_force_normal_flags (which I see no way to speed up). I have defined these conditionally with #ifndef, so that platform-spe- cific hints can override them with values appropriate to the platform. Also, refactor things in sv_setsv_flags slightly to avoid using SvLEN and SvCUR repeatedly.
* New COW mechanismFather Chrysostomos2012-11-271-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | This was discussed in ticket #114820. This new copy-on-write mechanism stores a reference count for the PV inside the PV itself, at the very end. (I was using SvEND+1 at first, but parts of the regexp engine expect to be able to do SvCUR_set(sv,0), which causes the wrong byte of the string to be used as the reference count.) Only 256 SVs can share the same PV this way. Also, only strings with allocated space after the trailing null can be used for copy-on-write. Much of the code is shared with PERL_OLD_COPY_ON_WRITE. The restric- tion against doing copy-on-write with magical variables has hence been inherited, though it is not necessary. A future commit will take care of that. I had to modify _core_swash_init to handle $@ differently. The exist- ing mechanism of copying $@ to a new scalar and back again was very fragile. With copy-on-write, $@ =~ s/// can cause pp_subst’s string pointers to become stale. So now we remove the scalar from *@ and allow the utf8-table-loading code to autovivify a new one. Then we restore the untouched $@ afterwards if all goes well.
* Move a CAN_COW_MASK comment from sv.c to sv.hFather Chrysostomos2012-11-251-0/+2
| | | | It got left behind in ed25273444 when the macro moved.
* SvPVXtrue single eval->multiple evalDaniel Dragan2012-11-231-9/+11
| | | | | | | | | | | | | | | | | | Make SvTRUE and SvPVXtrue smaller and faster in machine code on non GCC compilers. This commit implements my posts here, http://www.nntp.perl.org/group/perl.perl5.porters/2012/11/msg195720.html and in my commit message in commit 4cc783efe0 . SvPVXtrue was added in commit 4bac9ae47b . No reason was given why SvPVXtrue is single eval, but its only use is in multi eval SvTRUE. A non GCC compiler will write to PL_Xpv and PL_Sv, and still keep the SV * and PV *s in a register for the next operations/instructions. The writes to PL_Xpv and PL_Sv are needless. The use of PL_Xpv and PL_Sv is self explanatory C lang wise. As said in the ML post, this commit causes overall code bloat because of incorrect uses of passing macro args that make calls (ERRSV for example) to SvTRUE. This will have to be fixed in the future. All of the pp opcode funcs decrease tiny bit in size after this commit. See the ML list post for details.
* av_exists: dont make a mortal never to use itbulk88 (via RT)2012-11-231-0/+1
| | | | | | | | | | | | | | | | | Make av_exists slightly smaller and faster by reducing the liveness of a mortal SV and using a NN SvTRUE_nomg. There were 3 cases, where this mortal would be created, yet a return happened and the mortal went unused and was wasted. So move the mortal creation point closer to where it is first used. Also var sv will never be null, so use a NN version of SvTRUE_nomg created in commit [perl #115870]. The retbool line isn't actually required for optimization reasons, but was created just in case something in the future changes or some unknown compiler does something inefficiently. For me with 32 bit x86 VC 2003, before av_exists was 0x1C2, after 0x1B8. Comment from committer: Includes SvTRUE_nomg_NN from [perl #115870].
View Lorry Controller Status