The types are:
SVt_NULL SVt_BIND (unused) SVt_IV SVt_NV SVt_RV SVt_PV SVt_PVIV SVt_PVNV SVt_PVMG SVt_REGEXP SVt_PVGV SVt_PVLV SVt_PVAV SVt_PVHV SVt_PVCV SVt_PVFM SVt_PVIO
These are most easily explained from the bottom up.
SVt_PVIO is for I/O objects, SVt_PVFM for formats, SVt_PVCV for subroutines, SVt_PVHV for hashes and SVt_PVAV for arrays.
All the others are scalar types, that is, things that can be bound to a
$ variable. For these, the internal types are mostly orthogonal to types in the Perl language.
SvTYPE(sv) < SVt_PVAV is the best way to see whether something is a scalar.
SVt_PVGV represents a typeglob. If !SvFAKE(sv), then it is a real, incoercible typeglob. If SvFAKE(sv), then it is a scalar to which a typeglob has been assigned. Assigning to it again will stop it from being a typeglob. SVt_PVLV represents a scalar that delegates to another scalar behind the scenes. It is used, e.g., for the return value of
substr and for tied hash and array elements. It can hold any scalar value, including a typeglob. SVt_REGEXP is for regular expressions.
SVt_PVMG represents a "normal" scalar (not a typeglob, regular expression, or delegate). Since most scalars do not need all the internal fields of a PVMG, we save memory by allocating smaller structs when possible. All the other types are just simpler forms of SVt_PVMG, with fewer internal fields. SVt_NULL can only hold undef. SVt_IV can hold undef, an integer, or a reference. (SVt_RV is an alias for SVt_IV, which exists for backward compatibility.) SVt_NV can hold any of those or a double. SVt_PV can only hold undef or a string. SVt_PVIV is a superset of SVt_PV and SVt_IV. SVt_PVNV is similar. SVt_PVMG can hold anything SVt_PVNV can hold, but it can, but does not have to, be blessed or magical.
SV Manipulation Functions
All of the following SvREFCNT_inc* macros are optimized versions of SvREFCNT_inc, and can be replaced with SvREFCNT_inc.
This is also used to store the name of an autoloaded subroutine in an XS AUTOLOAD routine. See "Autoloading with XSUBs" in perlguts.
SvCUR is equal to
SvEND points to unallocated memory.
Beware that the existing pointer may be involved in copy-on-write or other mischief, so do
SvOOK_off(sv) and use
SvPV_force (or check the SvIsCOW flag) first to make sure this modification is safe.
Returns true if the SV has get magic or overloading. If either is true then the scalar is active data, and has the potential to return a new value every time it is accessed. Hence you must be careful to only read it once per user logical operation and work with that returned value. If neither is true then the scalar's value cannot change unless written to.
A quick flag check to see whether an sv should be passed to sv_force_normal to be "downgraded" before SvIVX or SvPVX can be modified directly.
For example, if your scalar is a reference and you want to modify the SvIVX slot, you can't just do SvROK_off, as that will leak the referent.
This is used internally by various sv-modifying functions, such as sv_setsv, sv_setiv and sv_pvn_force.
One case that this does not handle is a gv without SvFAKE set. After
if (SvTHINKFIRST(gv)) sv_force_normal(gv);
it will still be a gv.
SvTHINKFIRST sometimes produces false positives. In those cases sv_force_normal does nothing.
Note that coercing an arbitrary scalar into a plain PV will potentially strip useful data from it. For example if the SV was
SvROK, then the referent will have its reference count decremented, and the SV itself may be converted to an
SvPOK scalar with a string buffer containing a value such as
Note that there is no guarantee that the return value of
SvPV() is equal to
SvPVX(sv), or that
SvPVX(sv) contains valid data, or that successive calls to
SvPV(sv)) will return the same pointer value each time. This is due to the way that things like overloading and Copy-On-Write are handled. In these cases, the return value may point to a temporary buffer or similar. If you absolutely need the SvPVX field to be valid (for example, if you intend to write to it), then see "SvPV_force".
Like sv_utf8_upgrade, but doesn't do magic on
Creates an RV wrapper for an SV. The reference count for the original SV is incremented.
SV Manipulation Functions
Returns a true SV if
b is a true value, or a false SV if
b is 0.
Creates a new SV and copies a string into it. If utf8 is true, calls
SvUTF8_on on the new SV. Implemented as a wrapper around
Creates a new SV containing the pad name. This is currently identical to
newSVsv, but pad names may cease being SVs at some point, so
newSVpadname is preferable.
Reads into len the offset from SvPVX back to the true start of the allocated buffer, which will be non-zero if
sv_chop has been used to efficiently remove characters from start of the buffer. Implemented as a macro, which takes the address of len, which must be of type
STRLEN. Evaluates sv more than once. Sets len to 0 if
SvOOK(sv) is false.
1 POD Error
The following errors were encountered while parsing the POD:
- Around line 1492:
Unterminated C<...> sequence