summaryrefslogtreecommitdiff
path: root/sv.h
Commit message (Collapse)AuthorAgeFilesLines
* Fix a bunch of repeated-word typosDagfinn Ilmari Mannsåker2020-05-221-4/+4
| | | | | Mostly in comments and docs, but some in diagnostic messages and one case of 'or die die'.
* SvTRUE might need to take aTHXPaul "LeoNerd" Evans2020-03-011-1/+1
|
* Initial experiment at moving SvTRUE into a static inline macroPaul "LeoNerd" Evans2020-03-011-1/+1
|
* Clarify SvPVbyteFOO docsKarl Williamson2019-12-211-5/+8
| | | | These all croak if the SV string is in UTF-8 containing wide characters.
* sv.h: Fix typo in podKarl Williamson2019-12-161-2/+2
|
* Double the number of possible SV typesKarl Williamson2019-11-161-3/+6
| | | | | As per discussion beginning in http://nntp.perl.org/group/perl.perl5.porters/25656
* Some SvREFCNT_foo are no longer macrosKarl Williamson2019-09-151-6/+6
| | | | but are inline functions. They should be listed in embed.fnc.
* inline.h: Change fcn name prefix from S_ to Perl_Karl Williamson2019-09-151-7/+7
| | | | | | | | | | | | | | | | This is being done only for those functions that don't have a guard preventing them from being seen outside of the Perl core. Talking to Tony Cook, we agreed that this was a good idea for two reasons: 1) The 'Perl_' prefix does not pollute XS caller's name space. The 'S_' one could be argued that it doesn't much either, but it does more so than 'Perl_', and the next reason is the clincher: 2) It allows us to change our minds about whether a function should be static inline or not, without affecting callers who use the Perl_ form, which they would be accustomed to anyway if they're using the full name form.
* sv.h: SVt_INVLIST is core-onlyKarl Williamson2019-09-151-2/+2
|
* Improve grammar in podKarl Williamson2019-09-031-2/+2
| | | | for SvPV..._or_null, sv_utf8_downgraded_flags
* perlapi: Document SvUVXx()Karl Williamson2019-09-021-0/+3
| | | | I'm doing so because Devel::PPPort provides this function.
* Implement SvPV*_or_null*Pali2019-09-021-0/+32
|
* Implement SvPVutf8_nomg and SvPVbyte_nomgPali2019-09-021-0/+16
|
* Implement sv_utf8_downgrade_nomgPali2019-09-021-0/+2
|
* Fix apidoc macro entriesKarl Williamson2019-06-251-17/+17
| | | | | | | | | | This makes various fixes to the text that is used to generate the documentation. The dominant change is to add the 'n' flag to indicate that the macro takes no arguments. A couple should have been marked with a D (for deprecated) flag, and a couple were missing parameters, and a couple were missing return values. These were spotted by using Devel::PPPort on them.
* Document SvTRUEx() macroPali2019-06-191-0/+11
|
* Remove remaining assignments to SvCUR and SvLEN in coreDagfinn Ilmari Mannsåker2019-05-281-0/+15
| | | | Also make the macros non-lvalues under PERL_CORE
* Add newSVsv_nomg() macro which is like newSVsv() but does not process get magicPali2019-02-251-0/+5
| | | | Both newSVsv() and newSVsv_nomg() are now implemented via new Perl_newSVsv_flags() function.
* perlapi: Fix up SV handling podKarl Williamson2018-08-051-4/+0
| | | | | | | | | The pod for this has gotten screwed up over the releases, with a section entitled SV-Body Allocation containing a bunch of SV manipulation functions, and another section with that name containing still more with no real rhyme or reason as to why one would be in one vs the other. And one function was in both places. This commit consolidates all these into one section entitled "SV Manipulation Functions"
* remove stray NULLOK/NN from apidoc directivesZefram2017-12-061-3/+3
|
* Add isGV_or_RVCV macroFather Chrysostomos2017-10-081-0/+4
| | | | | This will be useful for a few code paths that need to treat a sub ref in a stash the same way as a GV.
* SvTRUE(): add code commentDavid Mitchell2017-08-041-1/+1
| | | | | explain that the '!= 0' is acting as a bool cast (since SvTRUE() is supposed to return a bool value rather than an int value).
* fix SvTRUE() cast (broke xor)David Mitchell2017-07-311-1/+1
| | | | | | | | | | | | | | RT #131820 It turns out that the 'xor' operator is almost completely untested in core. A recent change of mine to the SvTRUE() macros made it sometimes return an int (SvIVX(sv)) rather than a boolean (SvIVX(sv)!=0), while its documented to return a boolean. pp_xor() tests for (SvTRUE(left) != SvTRUE(right)) which subsequently broke, e.g. (1 xor 5) started returning true rather than false. Fix SvTRUE() and add some basic xor tests.
* SvTRUE(): inline ROK, outline NOKDavid Mitchell2017-07-271-3/+5
| | | | | | | | | | | | | | SvTRUE (and its variants) are wrappers around sv_2bool(), which attempt to test for the common cases without the overhead of a function call. This commit changes the definition of common: SvROK() becomes common: it's very common to test whether a variable is undef or a ref; SvNOK becomes uncommon: these days perl prefers IV values over NV values in SVs whenever possible, so testing the truth value of an NV is less common.
* SvTRUE(): special-case immortalsDavid Mitchell2017-07-271-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Immortal SVs like PL_sv_no will often be used as an argument to SvTRUE(); however it turns out that SvTRUE() is very inefficient at determining the truth value of such SVs. For example, for PL_sv_yes it does all the following test-and-branches to decide that it is indeed true: SvOK() SvPOK() SvANY() xpv_cur > 1 xpv_cur sv_u.svu_pv != '0' After the previous commit it is now much cheaper to test whether an SV is one of the four "interpreter" immortals PL_sv_yes, PL_sv_undef, PL_sv_no, PL_sv_zero. So this commit adds an extra check at the beginning of SvTRUE(): if it's an immortal, return whether it's a true immortal (i.e. PL_sv_yes). SvTRUE_nomg_NN(&PL_sv_yes) now only requires one test-and-branch plus an address comparison. The other immortals are similarly improved. Non-immortals now require one extra test-and-branch.
* Make immortal SVs contiguousDavid Mitchell2017-07-271-1/+14
| | | | | | | | | | | | | | | | | | | Ensure that PL_sv_yes, PL_sv_undef, PL_sv_no and PL_sv_zero are allocated adjacently in memory. This allows the SvIMMORTAL() test to be more efficient, and will (in the next commit) allow SvTRUE() to be more efficient. In MULTIPLICITY builds the constraint is already met by virtue of them being adjacent items in the interpreter struct. For non-MULTIPLICITY builds, they were just 4 global vars with no guarantees of where they would be allocated. For this case, PL_sv_undef are deleted as global vars and replaced with a new global var PL_sv_immortals[4], with #define PL_sv_yes (PL_sv_immortals[0]) etc in their place.
* SvTRUE(): handle get magic more efficientlyDavid Mitchell2017-07-271-1/+1
| | | | | | | SvTRUE() and SvTRUE_NN() are wrappers around sv_2bool() which handle the common cases directly and only fallback to sv_2bool() for the hard ones. Those macros were considering get magic as hard and falling back; instead, just call the get magic and continue.
* rationalise SvTRUE() macro variantsDavid Mitchell2017-07-271-4/+5
| | | | | | | | | | | define the plain, _nomg and _NN variants in terms of each other, e.g. #define SvTRUE(sv) (LIKELY(sv) && SvTRUE_NN(sv)) rather than duplicating common code text. There should be no functional changes, and the macros should (in theory) continue to expand to the same text.
* give REGEXP SVs the POK flag againDavid Mitchell2017-07-271-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit v5.17.5-99-g8d919b0 stopped SVt_REGEXP SVs (and PVLVs acting as regexes) from having the POK and pPOK flags set. This made things like SvOK() and SvTRUE() slower, because as well as the quick single test for any I/N/P/R flags, SvOK() also has to test for (SvTYPE(sv) == SVt_REGEXP || (SvFLAGS(sv) & (SVTYPEMASK|SVp_POK|SVpgv_GP|SVf_FAKE)) == (SVt_PVLV|SVf_FAKE)) This commit fixes the issue fixed by g8d919b0 in a slightly different way, which is less invasive and allows the POK flag. Background: PVLV are basically PVMGs with a few extra fields. They are intended to be a superset of all scalar types, so any scalar value can be assigned to a PVLV SV. However, once REGEXPs were made into first-class scalar SVs, this assumption broke - there are a whole bunch of fields in a regex SV body which can't be copied to to a PVLV. So this broke: sub f { my $r = qr/abc/; # $r is reference to an SVt_REGEXP $_[0] = $$r; } f($h{foo}); # the hash access is deferred - a temporary PVLV is # passed instead The basic idea behind the g8d919b0 fix was, for an LV-acting-as-regex, to attach both a PVLV body and a regex body to the SV head. This commit keeps this basic concept; it just changes how the extra body is attached. The original fix changed SVt_REGEXP SVs so that sv.sv_u.svu_pv no longer pointed to the regexp's string representation; instead this pointer was stored in a union made out of the xpv_len field. Doing this necessitated not turning the POK flag on for any REGEXP SVs. This freed up the sv_u to point to the regex body, while the sv_any field could continue to point to the PVLV body. An ReANY() macro was introduced that returned the sv_u field rather than the sv_any field. This commit changes it so that instead, on regexp SVs (and LV-as-regexp SVs), sv_u always points to the string buffer (so they can have POK set again), but on specifically LV-as-regex SVs, the xpv_len_u union of the PVLV body points to the regexp body. This means that SVt_REGEXP SVs are now completely "normal" again, and SVt_PVLV SVs are normal except in the one case where they hold a regex, in which case rather than storing the string buffer's length, the PVLV body stores a pointer to the regex body.
* add PL_sv_zeroDavid Mitchell2017-07-271-1/+1
| | | | | | | | | | it's like PL_sv_no, except that its string value is "0" rather than "". It can be used for example where pp function wants to push a zero return value on the stack. The next commit will start to use it. Also update the SvIMMORTAL() to be more efficient: it now checks whether the SV's address is in a range rather than individually checking against &PL_sv_undef, &PL_sv_no etc.
* Define and use symbolic constants for LvFLAGSDagfinn Ilmari Mannsåker2017-06-021-0/+4
|
* PATCH: [perl #130801] perlapi: Clarify SvIV/SvUV/SvNV behaviorPali2017-04-111-18/+33
| | | | [The committer made a few changes for improved readability]
* vec(): defer lvalue out-of-range croakingDavid Mitchell2017-03-311-1/+2
| | | | | | | | | | | | | | | | | | | | | RT #131083 Recent commits v5.25.10-81-gd69c430 and v5.25.10-82-g67dd6f3 added out-of-range/overflow checks for the offset arg of vec(). However in lvalue context, these croaks now happen before the SVt_PVLV was created, rather than when its set magic was called. This means that something like sub f { $x = $_[0] } f(vec($s, -1, 8)) now croaks even though the out-of-range value never ended up getting used in lvalue context. This commit fixes things by, in pp_vec(), rather than croaking, just set flag bits in LvFLAGS() to indicate that the offset is -Ve / out-of-range. Then in Perl_magic_getvec(), return 0 if these flags are set, and in Perl_magic_setvec() croak with a suitable error.
* sv.h: Add commentKarl Williamson2017-02-121-1/+4
|
* perlapi: Add clarification for SvGROW()Karl Williamson2017-01-051-0/+3
|
* SV_UTF8_NO_ENCODING is no longer usedKarl Williamson2017-01-021-1/+1
| | | | It once had meaning under 'use encoding';
* add comments explaining the point of SVf_PROTECTDavid Mitchell2016-11-241-0/+9
| | | | | The flag was added by v5.21.4-17-ga623f89, but outside of the commit message itself, there didn't seem to be any explanation for this flag.
* clarify what the SVf_AMAGIC meansDavid Mitchell2016-11-141-1/+6
|
* reduce cost of SvVALID()David Mitchell2016-11-131-1/+2
| | | | | | | | Now that SvVALID() no longer just checks an SV flag, but instead checks for the existence of a certain type of magic, avoid using this more expensive macro when its not really needed. Also, and an extra flag test to SvVALID() to make it fail quicker.
* eliminate SVpbm_VALID flagDavid Mitchell2016-11-121-41/+14
| | | | | | | | This flag is set on an SV to indicate that it has PERL_MAGIC_bm (fast Boyer-Moore) magic attached. Instead just directly check whether it has such magic. This frees up the 0x40000000 bit for anything except AVs and HVs
* eliminate SVpbm_TAIL/SvTAIL_on()/SvTAIL_off()David Mitchell2016-11-121-10/+6
| | | | | | | | | | | | (but keep SvTAIL()) This flag is only set on SVs that have Boyer-Moore magic attached. Such SVs already re-purpose the unused IVX slot of that SV to store BmUSEFUL. This commit repurposes the unused NVX slot to store this boolean value instead. Now that flag bit (0x80000000) is only used with AVs, HVs, RVs and scalar SVs with IOK.
* Only test SvTAIL when SvVALIDDavid Mitchell2016-11-121-0/+1
| | | | | | Only use the SvTAIL() macro when we've already confirmed that the SV is SvVALID() - this is in preparation for removing the SVpbm_TAIL flag in the next commit
* Eliminate SVrepl_EVAL and SvEVALED()David Mitchell2016-11-121-6/+1
| | | | | | | | | | | This flag is only used to indicate that the SV holding the text of the replacement part of a s/// has seen at least one /e. Instead, set the IVX field in the SV to a true value. (We already set the NVX field on that SV to indicate a multi-src-line substitution). This is to reduce the number of odd special cases for the SVpbm_VALID flag.
* remove DOES's usage of SvSCREAMDavid Mitchell2016-11-121-2/+1
| | | | | | | | | | | | | | | | Currently the SvSCREAM flag is set on a temporary SV whose string value is "isa", but where for the purposes of printing Can't call method "XXX" its name is treated as "DOES" rather than "isa". Instead, set the temp SV's PVX buffer to point to a special static string (PL_isa_DOES) whose value is "isa", but the where the error reporting code can compare the address with PL_isa_DOES and if so, print "DOES" instead. This is to reduce the number of odd special cases for the SvSCREAM flag.
* remove eval's usage of SvSCREAMDavid Mitchell2016-11-121-1/+0
| | | | | | | | Currently the SvSCREAM flag is set on the sv pointed to by cx->blk_eval.cur_text, to indicate that it is ref counted. Instead, use a spare bit in the blk_u16 field of the eval context. This is to reduce the number of odd special cases for the SvSCREAM flag.
* sv.c: add sv_setpv_bufsize() and SvPVCLEAR()Yves Orton2016-10-191-0/+5
| | | | | | | | | | The first can be used to wrap several SVPV steps into a single sub, and a wrapper macro which is the equivalent of $s= ""; but is optimized in various ways.
* Eliminate xpad_cop_seq from _xnvu unionDavid Mitchell2016-09-271-4/+1
| | | | | | | | | | | | | PVNV's used to be used to hold pad names (like '$lex'), but aren't used for this purpose any more. So eliminate the xpad_cop_seq part of the union. Since S_scan_subst() was using xnv_u.xpad_cop_seq.xlow to store a temporary line count, add a new union member for that. The main usage of this field on CPAN is to define COP_SEQ_RANGE_LOW()-style macros, so if the module is still using xpad_cop_seq for that purpose, it's already broken.
* first step to documenting the Internals namespaceYves Orton2016-08-141-1/+18
| | | | | | | | | | | After discussion, we have decided to document Internals. This is a first step doing so, with lib/Internals.pod. At the same time I updated sv.h that there were equivalents for SvREFCNT and SvREADONLY in the Internals namespace, this required adding docs for SvREADONLY. I also tweaked the test name in Porting/Maintainers.pm so that it pointed at Porting/Maintainers.pl to make it more obvious how to specify a maintainer for a new file.
* New bug numbers in *.[ch]Father Chrysostomos2016-07-291-1/+1
| | | | perl -pi -e 'BEGIN { %map = split " ", join "", `cat pb2rt.txt` } s/(?<!\d)\d{8}\.\d{3}(?!\d)/$& (#$map{$&})/g' *.[ch]
* Revert "More generalized fix for #127855"David Mitchell2016-05-031-7/+4
| | | | | | | | This reverts commit bcc9f606509ad2fad50e16f081103451b7dc49e1. This and the next commit revert the two commits that were an original fix for RT #127855, but which is fixed in a different way in a following commit. See the ticket for more details.
View Lorry Controller Status