B::SV
, B::AV
, B::HV
, and B::CV
objectsB::OP
objects or for walking op trees
B - The Perl Compiler
use B;
The B
module supplies classes which allow a Perl program to delve
into its own innards. It is the module used to implement the
``backends'' of the Perl compiler. Usage of the compiler does not
require knowledge of this module: see the O module for the
user-visible part. The B
module is of use to those who want to
write new compiler backends. This documentation assumes that the
reader knows a fair amount about perl's internals including such
things as SVs, OPs and the internal symbol table and syntax tree
of a program.
The B
module contains a set of utility functions for querying the
current state of the Perl interpreter; typically these functions
return objects from the B::SV and B::OP classes, or their derived
classes. These classes in turn define methods for querying the
resulting objects about their own internal state.
The B
module exports a variety of functions: some are simple
utility functions, others provide a Perl program with a way to
get an initial ``handle'' on an internal object.
B::SV
, B::AV
, B::HV
, and B::CV
objectsFor descriptions of the class hierarchy of these objects and the methods that can be called on them, see below, OVERVIEW OF CLASSES and SV-RELATED CLASSES.
sv_undef
.
sv_yes
.
sv_no
.
svref_2object(SVREF)
main_root
, this is the primary
way to get an initial ``handle'' on an internal perl data structure
which can then be followed with the other access methods.
The returned object will only be valid as long as the underlying OPs and SVs continue to exist. Do not attempt to use the object after the underlying structures are freed.
amagic_generation
.
PREFIX is the name of the SYMREF you're walking.
For example:
# Walk CGI's symbol table calling print_subs on each symbol. # Recurse only into CGI::Util:: walksymtable(\%CGI::, 'print_subs', sub { $_[0] eq 'CGI::Util::' }, 'CGI::');
print_subs()
is a B::GV method you have declared. Also see B::GV Methods, below.
B::OP
objects or for walking op treesFor descriptions of the class hierarchy of these objects and the methods that can be called on them, see below, OVERVIEW OF CLASSES and OP-RELATED CLASSES.
walkoptree_debug
(see below) has been called to turn debugging on then
the method walkoptree_debug
is called on each op before METHOD is
called.
walkoptree_debug(DEBUG)
walkoptree
. If the optional
DEBUG argument is non-zero, it sets the debugging flag to that. See
the description of walkoptree
above for what the debugging flag
does.
ppname(OPNUM)
hash(STR)
cast_I32(I)
-c
command-line option. Obviously, this
is only useful in a BEGIN block or else the flag is set too late.
cstring(STR)
perlstring(STR)
class(OBJ)
"::"
. This is used to turn "B::UNOP"
into
"UNOP"
for example.
The C structures used by Perl's internals to hold SV and OP
information (PVIV, AV, HV, ..., OP, SVOP, UNOP, ...) are modelled on a
class hierarchy and the B
module gives access to them via a true
object hierarchy. Structure fields which point to other objects
(whether types of SV or types of OP) are represented by the B
module as Perl objects of the appropriate class.
The bulk of the B
module is the methods for accessing fields of
these structures.
Note that all access is read-only. You cannot modify the internals by using this module. Also, note that the B::OP and B::SV objects created by this module are only valid for as long as the underlying objects exist; their creation doesn't increase the reference counts of the underlying objects. Trying to access the fields of a freed object will give incomprehensible results, or worse.
B::IV, B::NV, B::RV, B::PV, B::PVIV, B::PVNV, B::PVMG, B::BM, B::PVLV, B::AV, B::HV, B::CV, B::GV, B::FM, B::IO. These classes correspond in the obvious way to the underlying C structures of similar names. The inheritance hierarchy mimics the underlying C ``inheritance''. For 5.9.1 and later this is:
B::SV | +--------------+----------------------+ | | | B::PV B::IV B::RV | \ / \ | \ / \ | B::PVIV B::NV \ / \____ __/ \ / B::PVNV | | B::PVMG | +-----+----+------+-----+-----+ | | | | | | B::BM B::AV B::GV B::HV B::CV B::IO | | B::PVLV | B::FM
For 5.9.0 and earlier, PVLV is a direct subclass of PVMG, so the base of this diagram is
| B::PVMG | +------+-----+----+------+-----+-----+ | | | | | | | B::PVLV B::BM B::AV B::GV B::HV B::CV B::IO | | B::FM
Access methods correspond to the underlying C macros for field access,
usually with the leading ``class indication'' prefix removed (Sv, Av,
Hv, ...). The leading prefix is only left in cases where its removal
would cause a clash in method name. For example, GvREFCNT
stays
as-is since its abbreviation would clash with the ``superclass'' method
REFCNT
(corresponding to the C function SvREFCNT
).
svref_2object()
subroutine. This scalar and other data it points
at should be considered read-only: modifying them is neither safe nor
guaranteed to have a sensible effect.
FLAGS & SVf_IVisUV
. Perhaps you want the
int_value
method instead?
IV
in that it returns the correct
value regardless of whether it's stored signed or
unsigned.
die()
if the PV isn't
a reference.
It is the appropriate method to use if you need to get the name of a lexical variable from a padname array. Lexical variable names are always stored with a null terminator, and the length field (SvCUR) is overloaded for other purposes and can't be relied on here.
die()
if called on r-magic.
It's useful if you want to print out the name of a variable.
If you restrict yourself to globs which exist at compile-time
then the result ought to be unambiguous, because code like
${"^G"} = 1
is compiled as two ops - a constant string and
a dereference (rv2gv) - so that the glob is created at runtime.
If you're working with globs at runtime, and need to disambiguate *^G from *{``^G''}, then you should use the raw NAME method.
IsSTD('stderr')
is true if
IoIFP($io)
== PerlIO_stdin()
).
ARRAY
, but takes an index as an argument to get only one element,
rather than a list of all of them.
B::OP
, B::UNOP
, B::BINOP
, B::LOGOP
, B::LISTOP
, B::PMOP
,
B::SVOP
, B::PADOP
, B::PVOP
, B::LOOP
, B::COP
.
These classes correspond in the obvious way to the underlying C structures of similar names. The inheritance hierarchy mimics the underlying C ``inheritance'':
B::OP | +---------------+--------+--------+ | | | | B::UNOP B::SVOP B::PADOP B::COP ,' `-. / `--. B::BINOP B::LOGOP | | B::LISTOP ,' `. / \ B::LOOP B::PMOP
Access methods correspond to the underlying C structre field names,
with the leading ``class indication'' prefix ("op_"
) removed.
These methods get the values of similarly named fields within the OP
data structure. See top of op.h
for more info.
Malcolm Beattie, mbeattie@sable.ox.ac.uk