summaryrefslogtreecommitdiff
path: root/sv.h
Commit message (Collapse)AuthorAgeFilesLines
* 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].
* refactor pp_stringify and pp_andDaniel Dragan2012-11-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pp_stringify: First, move all the SP/stack operations to before the first call in pp_stringify (sv_copypv), this allows SP to never be saved across any calls. SETTARG calls set magic, so that still has to be done. SETs does not ++/-- SP, so no need to do a PUTBACK. PL_op is read twice, once for TARG, once for NORMAL. No point in caching it through the sv_copypv call since its not worth saving a non-vol to C stack (x86) just to avoid 2 mem acesses. This opcode now only has 2 vars saved across sv_copypv, my_perl and TARG. pp_stringify dropped from 0x3F to 0x3C for me after these changes, 32 bit x86 VC 2003. pp_and: Do the PERL_ASYNC_CHECK before anything else, calcing SP before PERL_ASYNC_CHECK would mean saving it across the potential call. SvTRUE macro checks its param for NULL. This SV * came off the Perl stack, it will not be null since pp_and is not a core sub (see S_maybe_add_coresub) and will not be called from pp_coreargs (pp_coreargs places (SV *)NULLs on Perl stack). So create a SvTRUE_NN macro that does not check for NULL, this saves a branch. Since the Perl stack is only touched twice, don't create a local SP. See comment in code. This saves another variable to not be saved across the sv_2bool_flags and removed PUTBACK instructions. PL_op is only read once or twice (compiler choice) right before the 2 returns. There is only 1 variable saved across any calls in pp_and now, and that is my_perl. dSP also was not use to prevent an accidental use of a ++/-- SP macro in pp_and in the future since there is no PUTBACK now. I guess for a SPARC with register windowing and no direct memory instructions, accessing PL_stack_sp twice will take more instructions 2 reads and a write to PL_stack_sp vs 1 read and 1 write to PL_stack_sp with a dSP design. On SPARC, with a register window, cross call regs have no cost per reg cost aslong as you dont exceed their max number. For me, pp_and went from 0x112 to 0xFF after this commit. Prior to dSP removal, it was down to 0x109. SvTRUE_NN was named after SvREFCNT_inc_NN. There remains an inefficiency in pp_and on non-GCC compilers due to SvPVXtrue using PL_Xpv which will be dealt with in another commit.
* Hash Function Change - Murmur hash and true per process hash seedYves Orton2012-11-171-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does the following: *) Introduces multiple new hash functions to choose from at build time. This includes Murmur-32, SDBM, DJB2, SipHash, SuperFast, and One-at-a-time. Currently this is handled by muning hv.h. Configure support hopefully to follow. *) Changes the default hash to Murmur hash which is faster than the old default One-at-a-time. *) Rips out the old HvREHASH mechanism and replaces it with a per-process random hash seed. *) Changes the old PL_hash_seed from an interpreter value to a global variable. This means it does not have to be copied during interpreter setup or cloning. *) Changes the format of the PERL_HASH_SEED variable to a hex string so that hash seeds longer than fit in an integer are possible. *) Changes the return of Hash::Util::hash_seed() from a number to a string. This is to accomodate hash functions which have more bits than can be fit in an integer. *) Adds new functions to Hash::Util to improve introspection of hashes -) hash_value() - returns an integer hash value for a given string. -) bucket_info() - returns basic hash bucket utilization info -) bucket_stats() - returns more hash bucket utilization info -) bucket_array() - which keys are in which buckets in a hash More details on the new hash functions can be found below: Murmur Hash: (v3) from google, see http://code.google.com/p/smhasher/wiki/MurmurHash3 Superfast Hash: From Paul Hsieh. http://www.azillionmonkeys.com/qed/hash.html DJB2: a hash function from Daniel Bernstein http://www.cse.yorku.ca/~oz/hash.html SDBM: a hash function sdbm. http://www.cse.yorku.ca/~oz/hash.html SipHash: by Jean-Philippe Aumasson and Daniel J. Bernstein. https://www.131002.net/siphash/ They have all be converted into Perl's ugly macro format. I have not done any rigorous testing to make sure this conversion is correct. They seem to function as expected however. All of them use the random hash seed. You can force the use of a given function by defining one of PERL_HASH_FUNC_MURMUR PERL_HASH_FUNC_SUPERFAST PERL_HASH_FUNC_DJB2 PERL_HASH_FUNC_SDBM PERL_HASH_FUNC_ONE_AT_A_TIME Setting the environment variable PERL_HASH_SEED_DEBUG to 1 will make perl output the current seed (changed to hex) and the hash function it has been built with. Setting the environment variable PERL_HASH_SEED to a hex value will cause that value to be used at the seed. Any missing bits of the seed will be set to 0. The bits are filled in from left to right, not the traditional right to left so setting it to FE results in a seed value of "FE000000" not "000000FE". Note that we do the hash seed initialization in perl_construct(). Doing it via perl_alloc() (via init_tls) causes problems under threaded builds as the buffers used for reentrant srand48 functions are not allocated. See also the p5p mail "Hash improvements blocker: portable random code that doesnt depend on a functional interpreter", Message-ID: <CANgJU+X+wNayjsNOpKRqYHnEy_+B9UH_2irRA5O3ZmcYGAAZFQ@mail.gmail.com>
* SVf_IsCOWFather Chrysostomos2012-11-141-12/+9
| | | | | | | | | | | | | | | As discussed in ticket #114820, instead of using READONLY+FAKE to mark a copy-on-write string, we should make it a separate flag. There are many modules in CPAN (and 1 in core, Compress::Raw::Zlib) that assume that SvREADONLY means read-only. Only one CPAN module, POSIX::pselect will definitely be broken by this. Others may need to be tweaked. But I believe this is for the better. It causes all tests except ext/Devel-Peek/t/Peek.t (which needs a tiny tweak still) to pass under PERL_OLD_COPY_ON_WRITE, which is a prereq- uisite for any new COW scheme that creates COWs under the same cir- cumstances.
* Add C define to remove taint support from perlSteffen Mueller2012-11-051-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By defining NO_TAINT_SUPPORT, all the various checks that perl does for tainting become no-ops. It's not an entirely complete change: it doesn't attempt to remove the taint-related interpreter variables, but instead virtually eliminates access to it. Why, you ask? Because it appears to speed up perl's run-time significantly by avoiding various "are we running under taint" checks and the like. This change is not in a state to go into blead yet. The actual way I implemented it might raise some (valid) objections. Basically, I replaced all uses of the global taint variables (but not PL_taint_warn!) with an extra layer of get/set macros (TAINT_get/TAINTING_get). Furthermore, the change is not complete: - PL_taint_warn would likely deserve the same treatment. - Obviously, tests fail. We have tests for -t/-T - Right now, I added a Perl warn() on startup when -t/-T are detected but the perl was not compiled support it. It might be argued that it should be silently ignored! Needs some thinking. - Code quality concerns - needs review. - Configure support required. - Needs thinking: How does this tie in with CPAN XS modules that use PL_taint and friends? It's easy to backport the new macros via PPPort, but that doesn't magically change all code out there. Might be harmless, though, because whenever you're running under NO_TAINT_SUPPORT, any check of PL_taint/etc is going to come up false. Thus, the only CPAN code that SHOULD be adversely affected is code that changes taint state.
View Lorry Controller Status