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.
$
Hence, checking SvTYPE(sv) < SVt_PVAV is the best way to see whether something is a scalar.
SvTYPE(sv) < SVt_PVAV
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.
substr
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.
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.
Warning: If SvCUR is equal to SvLEN, then SvEND points to unallocated memory.
SvCUR
SvLEN
SvEND
Beware that the existing pointer may be involved in copy-on-write or other mischief, so do SvOOK_off(sv) and use sv_force_normal or SvPV_force (or check the SvIsCOW flag) first to make sure this modification is safe.
SvOOK_off(sv)
sv_force_normal
SvPV_force
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 "ARRAY(0x1234)".
SvROK
SvPOK
"ARRAY(0x1234)"
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".
SvPV()
SvPVX(sv)
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 sv.
sv
Creates an RV wrapper for an SV. The reference count for the original SV is incremented.
Returns a true SV if b is a true value, or a false SV if b is 0.
b
See also PL_sv_yes and PL_sv_no.
PL_sv_yes
PL_sv_no
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 newSVpvn_flags.
SvUTF8_on
newSVpvn_flags
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.
newSVsv
newSVpadname
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.
sv_chop
STRLEN
SvOOK(sv)
1 POD Error
The following errors were encountered while parsing the POD:
Unterminated C<...> sequence
To install vars, copy and paste the appropriate command in to your terminal.
cpanm
cpanm vars
CPAN shell
perl -MCPAN -e shell install vars
For more information on module installation, please visit the detailed CPAN module installation guide.