summaryrefslogtreecommitdiff
path: root/sv.h
Commit message (Collapse)AuthorAgeFilesLines
* More PAD APIsFather Chrysostomos2012-08-211-0/+12
| | | | | | | | | | | | | | | | If we are making padlists their own type, and no longer AVs, it makes sense to add APIs for pads, too, so that CPAN code that needs to change now will only have to change once if we ever stop pads them- selves from being AVs. There is no reason pad names have to be SVs, so I am adding sep- arate APIs for pad names, too. The AV containing pad names is now officially a PADNAMELIST, which is accessed, not via *PADLIST_ARRAY(padlist), but via PADLIST_NAMES(padlist). Future optimisations may even merge the padlist with its name list so I have also added macros to access the parts of the name list directly from the padlist.
* Use PADLIST in more placesFather Chrysostomos2012-08-211-1/+1
| | | | | Much code relies on the fact that PADLIST is typedeffed as AV. PADLIST should be treated as a distinct type.
* Static inline functions for SvPADTMP and SvPADSTALEFather Chrysostomos2012-08-211-45/+4
| | | | | This allows non-GCC compilers to have assertions and avoids repeating the macros.
* Use fast SvREFCNT_dec for non-GCCFather Chrysostomos2012-08-211-16/+1
|
* Use static inline functions for SvREFCNT_incFather Chrysostomos2012-08-211-36/+4
| | | | | | This avoids the need to repeat the macros in GCC and non-GCC versions. For non-GCC compilers capable of inlining, this should speed things up slightly, too, as PL_Sv is no longer needed.
* sv.h: Don’t repeat _XPV_HEADFather Chrysostomos2012-08-171-16/+8
|
* Restore VC++ 6 build on WindowsSteve Hay2012-08-181-0/+19
| | | | | | | | | | | Commits bb02a38feb and 1bd3586145 resulted in VC++ 6 complaining "error C2099: initializer is not a constant" when initializing bodies_by_type in sv.c. Workaround the apparent compiler bug using a patch from Jan Dubois, amended to be compiler-specific as suggested by Nicholas Clark since anonymous unions are not valid C89. Date: Wed, 15 Aug 2012 00:55:06 -0700 Message-ID: <005a01cd7abb$498294e0$dc87bea0$@activestate.com>
* Insert missing words into SvPV_force* documentationSteve Hay2012-08-131-2/+2
|
* assert_(...)Father Chrysostomos2012-08-051-15/+5
| | | | | | | | This new macro expands to ‘assert(...),’ (with a trailing comma) under debugging builds; the empty string otherwise. It allows for the removal of some #ifdef DEBUGGINGs, which could not be avoided otherwise.
* Add a depth field to formatsFather Chrysostomos2012-08-051-1/+6
| | | | | Instead of lengthening the struct, we can reuse SvCUR, which is cur- rently unused.
* Make PL_(top|body|form)target PVIVsFather Chrysostomos2012-08-051-2/+1
| | | | | | | | | | | | | These are only used for storing a string and an IV. Making them into full-blown SVt_PVFMs is overkill. FmLINES was only being used on these three scalars. So make it use the SvIVX field. struct xpvfm no longer needs an xfm_lines member, because SVt_PVFMs no longer use it. This also causes a TODO test in taint.t to start passing, but I do not fully understand why. But at least that’s progress. :-)
* sv.h: Document SvTHINKFIRSTFather Chrysostomos2012-07-281-0/+24
|
* Oust sv_gmagical_2iv_pleaseFather Chrysostomos2012-07-281-6/+1
| | | | | | | The magic flags patch prevents this from ever being called, since the OK flags work the same way for magic variables now as they have for muggle vars, avoid these fiddly games. (It was when writing it that I realised the value of the magic flags proposal.)
* Flatten vstrings modified in placeFather Chrysostomos2012-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A substitution forces its target to a string upon successful substitu- tion, even if the substitution did nothing: $ ./perl -Ilib -le '$a = *f; $a =~ s/f/f/; print ref \$a' SCALAR Notice that $a is no longer a glob after s///. But vstrings are different: $ ./perl -Ilib -le '$a = v102; $a =~ s/f/f/; print ref \$a' VSTRING I fixed this in 5.16 (1e6bda93) for those cases where the vstring ends up with a value that doesn’t correspond to the actual string: $ ./perl -Ilib -le '$a = v102; $a =~ s/f/o/; print ref \$a' SCALAR It works through vstring set-magic, that does the check and removes the magic if it doesn’t match. I did it that way because I couldn’t think of any other way to fix bug #29070, and I didn’t realise at the time that I hadn’t fixed all the bugs. By making SvTHINKFIRST true on a vstring, we force it through sv_force_normal before any in-place string operations. We can also make sv_force_normal handle vstrings as well. This fixes all the lin- gering-vstring-magic bugs in just two lines, making the vstring set- magic (which is also slow) redundant. It also allows the special case in sv_setsv_flags to be removed. Or at least that was what I had hoped. It turns out that pp_subst, twists and turns in tortuous ways, and needs special treatment for things like this. And do_trans functions wasn’t checking SvTHINKFIRST when arguably it should have. I tweaked sv_2pv{utf8,byte} to avoid copying magic variables that do not need copying.
* Make all the SvPV*force* macros always return sv with SvPOK_only, as APIChip Salzenberg2012-07-261-11/+18
| | | | docs always claimed they did. Also update those docs to be clearer.
* make SvOOK_offset macro safer, with parens and underscoresChip Salzenberg2012-07-201-14/+14
|
* Magic flags harmonization.Chip Salzenberg2012-07-151-94/+75
| | | | | | | | | | | | | | | | | | | | | | | | | In restore_magic(), which is called after any magic processing, all of the public OK flags have been shifted into the private OK flags. Thus the lack of an appropriate public OK flags was used to trigger both get magic and required conversions. This scheme did not cover ROK, however, so all properly written code had to make sure mg_get was called the right number of times anyway. Meanwhile the private OK flags gained a second purpose of marking converted but non-authoritative values (e.g. the IV conversion of an NV), and the inadequate flag shift mechanic broke this in some cases. This patch removes the shift mechanic for magic flags, thus exposing (and fixing) some improper usage of magic SVs in which mg_get() was not called correctly. It also has the side effect of making magic get functions specifically set their SVs to undef if that is desired, as the new behavior of empty get functions is to leave the value unchanged. This is a feature, as now get magic that does not modify its value, e.g. tainting, does not have to be special cased. The changes to cpan/ here are only temporary, for development only, to keep blead working until upstream applies them (or something like them). Thanks to Rik and Father C for review input.
* sv.h: Improve docs of Sv[GS]ETMAGICFather Chrysostomos2012-07-031-2/+5
|
* sv.h: Move comment just before struct it describesFather Chrysostomos2012-06-151-2/+2
| | | | It was divorced therefrom in commit 20f4945e.
* sv.h: Comment typoFather Chrysostomos2012-06-081-1/+1
|
* [perl #109542] Make num ops treat $1 as "$1"Father Chrysostomos2012-06-071-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Numeric ops were not taking magical variables into account. So $1 (a magical variable) would be treated differently from "$1" (a non-magi- cal variable0. In determining whether to use an integer operation, they would call SvIV_please_nomg, and then check whether the sv was SvIOK as a result. SvIV_please_nomg would call SvIV_nomg if the sv were SvPOK or SvNOK. The problem here is that gmagical variables are never SvIOK, but only SvIOKp. In fact, the private flags are used differently for gmagical and non- magical variables. For non-gmagical variables, the private flag indi- cates that there is a cached value. If the public flag is not set, then the cached value is imprecise. For gmagical variables, imprecise values are never cached; only the private flags are used, and they are equivalent to the public flags on non-gmagical variables. This commit changes SvIV_please_nomg to take gmagical variables into account, using the newly-added sv_gmagical_2iv_please (see the docs for it in the diff). SvIV_please_nomg now returns true or false, not void, since a subsequent SvIOK is not reliable. So ‘SvIV_please_nomg(sv); if(SvIOK)’ becomes ‘if(SvIV_please_nomg(sv))’.
* sv.h: Document the only use of SvSCREAMFather Chrysostomos2012-05-291-2/+2
| | | | | Now that studied scalars are gone, SvSCREAM is used only for the DOES method name hack, so update sv.h accordingly.
* update the editor hints for spaces, not tabsRicardo Signes2012-05-291-2/+2
| | | | | This updates the editor hints in our files for Emacs and vim to request that tabs be inserted as spaces.
* Check HvNAME in Gv_AMGFather Chrysostomos2012-05-211-1/+3
| | | | | | | | | | | | | If a stash is undeffed, simple stringification could cause method lookup to croak, because Gv_AMupdate is trying to look up methods to fill the overload table. Gv_AMupdate could be called to begin with because the isa and method changes now cause the AMAGIC flag to be set on the stash. It was for this reason that I added HvAMAGIC_off to hv_undef. But putting the name check here seems a much more robust solution, as mro linearisation triggered by hv_undef could croak, causing the flag not to be unset by hv_undef.
* sv.h: define SvAMAGIC in terms of HvAMAGICFather Chrysostomos2012-05-211-5/+3
|
* sv.h: Turn off AMAGIC flag in Gv_AMGFather Chrysostomos2012-05-211-1/+2
| | | | | | | | | | | | | | | | | | This makes no functional changes. If a stash has its AMAGIC flag on, then when the overload caches are updated we can turn off the flag if it turns out that there is no overloading. Gv_AMG is the easiest place to unset this flag, as Gv_AMupdate has ‘return 0’ in more than one place. This is for efficiency’s sake, as an object that inherits overloading but then loses it through @ISA changes will still have to go through extra checks due to SvAMAGIC returning true. This also offsets an inefficiency to be introduced in later commits: changes to @ISA will set the AMAGIC flag.
* sv.h: Add HvAMAGIC macrosFather Chrysostomos2012-05-211-0/+5
| | | | | | These are the only Hv* macros in sv.h, so I may be putting them in the wrong place. However, they are very closely related to those that immediately precede them.
* Don’t check PL_amagic_generation in Gv_AMGFather Chrysostomos2012-05-211-1/+1
| | | | | Because version.pm is now part of perl, PL_amagic_generation is always non-zero, so there’s no point in doing that check.
* Move SvAMAGIC flag from object to stashFather Chrysostomos2012-05-211-6/+13
| | | | | | | | | | | | | | | | | By putting the flag on the stash, we can allow the overloaded status of all objects of a particular class to change without having to change the flag on every object (which would require traversing arenas or keeping caches). This partially fixes bug #112708, in that objects that existed before their class had any overloading will start working after overloading is introduced if other objects are blessed into that class. Without blessings of other objects, they still don’t work yet. The fix for that is yet to come.... This was also a good excuse for deleting a comment that contained two typos. :-)
* perlapi (from sv.h) clarificationsKarl Williamson2012-03-191-2/+4
|
* fix slowdown in nested hash freeingDavid Mitchell2012-03-061-0/+1
| | | | | | | | | | | | | | Commit 104d7b69 made sv_clear free hashes iteratively rather than recursively; however, my code didn't record the current hash index when freeing a nested hash, which made the code go quadratic when freeing a large hash with inner hashes, e.g.: my $r; $r->{$_} = { a => 1 } for 1..10_0000; This was noticeable on such things as CPAN.pm being very slow to exit. This commit fixes this by squirrelling away the old hash index in the now-unused SvMAGIC field of the hash being freed.
* sv_force_normal: Don’t confuse regexps with cowsFather Chrysostomos2012-01-221-1/+2
| | | | | Otherwise we get assertion failures and possibly corrupt string tables.
* Fix bad reference in sv.h’s docsFather Chrysostomos2011-12-301-1/+1
| | | | SvPVx should be referring to SvPV as the faster version, not SvPVX.
* Adjust substr offsets when using, not when creating, lvalueFather Chrysostomos2011-12-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When substr() occurs in potential lvalue context, the offsets are adjusted to the current string (negative being converted to positive, lengths reaching beyond the end of the string being shortened, etc.) as soon as the special lvalue to be returned is created. When that lvalue is assigned to, the original scalar is stringified once more. That implementation results in two bugs: 1) Fetch is called twice in a simple substr() assignment (except in void context, due to the special optimisation of commit 24fcb59fc). 2) These two calls are not equivalent: $SIG{__WARN__} = sub { warn "w ",shift}; sub myprint { print @_; $_[0] = 1 } print substr("", 2); myprint substr("", 2); The second one dies. The first one only warns. That’s mean. The error is also wrong, sometimes, if the original string is going to get longer before the substr lvalue is actually used. The behaviour of \substr($str, -1) if $str changes length is com- pletely undocumented. Before 5.10, it was documented as being unreli- able and subject to change. What this commit does is make the lvalue returned by substr remember the original arguments and only adjust the offsets when the assign- ment happens. This means that the following now prints z, instead of xyz (which is actually what I would expect): $str = "a"; $substr = \substr($str,-1); $str = "xyz"; print $substr;
* Bring SvOOK_on back, but simplerFather Chrysostomos2011-12-011-0/+1
| | | | | | | | | | | Commit 404dce59 removed it, because nothing in core or CPAN was using it and it is not part of the API. Nothing in core was using it because it was unusable as previously defined (with SvIOK_off). This commit brings it back, but now it is a simple flag-setting macro, that will actually be usable by the core.
* Remove SvOOK_onFather Chrysostomos2011-11-301-1/+0
| | | | Nothing is using in core or on CPAN. It is not part of the API.
* Remove obsolete comment about SvPOKp in sv.hFather Chrysostomos2011-11-291-4/+0
| | | | | This comment was added in 373b357f1, and then invalidated by the same person in 8eeaf79a, seventeen days later.
* Remove duplicate comment from sv.hFather Chrysostomos2011-11-271-1/+1
| | | | | | | | | | The ‘or lexical’ in this ‘glob or lexical is just a copy’ comment was added in perl 5.001 (748a9306), which added closures. This comment was later duplicated in commit 120ff8e9d (‘Document a sixth use for SVf_FAKE’), but in a clearer fashion. This commit removes the ‘or lexical’ part, as it is now confusing.
* sv.h: Consistent use of spaces after dotsFather Chrysostomos2011-11-261-25/+30
|
* [perl #97632] Improve SvTAINT docsFather Chrysostomos2011-11-261-1/+5
| | | | Copied almost verbatim from text supplied by Kevin Ryde.
* [RT #36079] Convert ` to '.jkeenan2011-11-221-1/+1
|
* document boolSV(), which is used in the default typemapTony Cook2011-10-171-0/+10
|
* Improve documentation of XS autoloadingFather Chrysostomos2011-10-111-4/+2
|
* Update docs for XS AUTOLOADFather Chrysostomos2011-10-091-0/+5
| | | | | This mentions the UTF8 flag and moves the discussion to perlapi, where it belongs, IMHO.
* Correct SvEND docsFather Chrysostomos2011-10-081-1/+6
| | | | | SvEND does not point to the last character, but to a spot just after it.
* renumber SVpad_STATE and free a bit in SvFLAGSDavid Mitchell2011-10-071-2/+3
| | | | | | SVpad_STATE is only used on SVs which hold PAD names; make it share the same flags bit as SVprv_WEAKREF/SVf_IVisUV. Together with the previous commit, this frees up a single bit in SvFLAGS, 0x00010000.
* make SVs_PADTMP and SVs_PADSTALE share a bitDavid Mitchell2011-10-071-20/+28
| | | | | | | | | | | SVs_PADSTALE is only meaningful with SVs_PADMY, while SVs_PADTMP is only meaningful with !SVs_PADMY, so let them share the same flag bit. Note that this doesn't yet free a bit in SvFLAGS, as the two bits are also used for SVpad_STATE, SVpad_TYPED. (This is is follow-on to 62bb6514085e5eddc42b4fdaf3713ccdb7f1da85.)
* mro.c: Correct utf8 and bytes concatenationFather Chrysostomos2011-10-061-0/+6
| | | | | | | | | | | | | | | | | | | The previous commit introduced some code that concatenates a pv on to an sv and then does SvUTF8_on on the sv if the pv was utf8. That can’t work if the sv was in Latin-1 (or single-byte) encoding and contained extra-ASCII characters. Nor can it work if bytes are appended to a utf8 sv. Both produce mangled utf8. There is apparently no function apart from sv_catsv that handle this. So I’ve modified sv_catpvn_flags to handle this if passed the SV_CATUTF8 (concatenating a utf8 pv) or SV_CATBYTES (cancatenating a byte pv) flag. This avoids the overhead of creating a new sv (in fact, sv_catsv even copies its rhs in some cases, so that would mean creating two new svs). It might even be worthwhile to redefine sv_catsv in terms of this....
* Add MAYBE_DEREF_GV macroFather Chrysostomos2011-09-101-1/+1
| | | | | | | | | | | | | | | | | There are so many parts of the core (mostly pp functions or functions they call) that need a glob or a globref, including many that call get-magic at the wrong time (or not at all in some cases, that it makes sense to add a macro to do it. It can be used like this: if (gv = MAYBE_DEREF_GV(sv)) /* calls get-magic */ { } else { /* avoid magic here */ }
* replace many SvTYPE assertions with lookup tablesDavid Mitchell2011-07-151-63/+26
| | | | | Under a DEBUGGING build, this reduces the size of the perl binary by about 10%, and reduces the time to run the test suite by about 10-20%% (!)
View Lorry Controller Status