Perl also uses two special typedefs, I32 and I16, which will always be at
least 32-bits and 16-bits long, respectively. (Again, there are U32 and U16,
-as well.)
+as well.) They will usually be exactly 32 and 16 bits long, but on Crays
+they will both be 64 bits.
=head2 Working with SVs
-An SV can be created and loaded with one command. There are four types of
-values that can be loaded: an integer value (IV), a double (NV),
-a string (PV), and another scalar (SV).
+An SV can be created and loaded with one command. There are five types of
+values that can be loaded: an integer value (IV), an unsigned integer
+value (UV), a double (NV), a string (PV), and another scalar (SV).
-The six routines are:
+The seven routines are:
SV* newSViv(IV);
+ SV* newSVuv(UV);
SV* newSVnv(double);
SV* newSVpv(const char*, int);
SV* newSVpvn(const char*, int);
SV* newSVpvf(const char*, ...);
SV* newSVsv(SV*);
-To change the value of an *already-existing* SV, there are seven routines:
+If you require more complex initialisation you can create an empty SV with
+newSV(len). If C<len> is 0 an empty SV of type NULL is returned, else an
+SV of type PV is returned with len + 1 (for the NUL) bytes of storage
+allocated, accessible via SvPVX. In both cases the SV has value undef.
+
+ SV* newSV(0); /* no storage allocated */
+ SV* newSV(10); /* 10 (+1) bytes of uninitialised storage allocated */
+
+To change the value of an *already-existing* SV, there are eight routines:
void sv_setiv(SV*, IV);
void sv_setuv(SV*, UV);
void sv_setpv(SV*, const char*);
void sv_setpvn(SV*, const char*, int)
void sv_setpvf(SV*, const char*, ...);
- void sv_setpvfn(SV*, const char*, STRLEN, va_list *, SV **, I32, bool);
+ void sv_vsetpvfn(SV*, const char*, STRLEN, va_list *, SV **, I32, bool *);
void sv_setsv(SV*, SV*);
Notice that you can choose to specify the length of the string to be
The arguments of C<sv_setpvf> are processed like C<sprintf>, and the
formatted output becomes the value.
-C<sv_setpvfn> is an analogue of C<vsprintf>, but it allows you to specify
+C<sv_vsetpvfn> is an analogue of C<vsprintf>, but it allows you to specify
either a pointer to a variable argument list or the address and length of
an array of SVs. The last argument points to a boolean; on return, if that
boolean is true, then locale-specific information has been used to format
void sv_catpv(SV*, const char*);
void sv_catpvn(SV*, const char*, STRLEN);
void sv_catpvf(SV*, const char*, ...);
- void sv_catpvfn(SV*, const char*, STRLEN, va_list *, SV **, I32, bool);
+ void sv_vcatpvfn(SV*, const char*, STRLEN, va_list *, SV **, I32, bool);
void sv_catsv(SV*, SV*);
The first function calculates the length of the string to be appended by
Perl provides the function C<sv_chop> to efficiently remove characters
from the beginning of a string; you give it an SV and a pointer to
-somewhere inside the the PV, and it discards everything before the
+somewhere inside the PV, and it discards everything before the
pointer. The efficiency comes by means of a little hack: instead of
actually removing the characters, C<sv_chop> sets the flag C<OOK>
(offset OK) to signal to other functions that the offset hack is in
shown in parentheses, and the values of C<SvCUR> and C<SvLEN> reflect
the fake beginning, not the real one.
-Something similar to the offset hack is perfomed on AVs to enable
+Something similar to the offset hack is performed on AVs to enable
efficient shifting and splicing off the beginning of the array; while
C<AvARRAY> points to the first element in the array that is visible from
Perl, C<AvALLOC> points to the real start of the C array. These are
/* Get the key from an HE structure and also return
the length of the key string */
SV* hv_iterval(HV*, HE* entry);
- /* Return a SV pointer to the value of the HE
+ /* Return an SV pointer to the value of the HE
structure */
SV* hv_iternextsv(HV*, char** key, I32* retlen);
/* This convenience routine combines hv_iternext,
There are additional macros whose values may be bitwise OR'ed with the
C<TRUE> argument to enable certain extra features. Those bits are:
- GV_ADDMULTI Marks the variable as multiply defined, thus preventing the
- "Name <varname> used only once: possible typo" warning.
- GV_ADDWARN Issues the warning "Had to create <varname> unexpectedly" if
- the variable did not exist before the function was called.
+=over
+
+=item GV_ADDMULTI
+
+Marks the variable as multiply defined, thus preventing the:
+
+ Name <varname> used only once: possible typo
+
+warning.
+
+=item GV_ADDWARN
+
+Issues the warning:
+
+ Had to create <varname> unexpectedly
+
+if the variable did not exist before the function was called.
+
+=back
If you do not specify a package name, the variable is created in the current
package.
=head2 Reference Counts and Mortality
-Perl uses an reference count-driven garbage collection mechanism. SVs,
+Perl uses a reference count-driven garbage collection mechanism. SVs,
AVs, or HVs (xV for short in the following) start their life with a
reference count of 1. If the reference count of an xV ever drops to 0,
then it will be destroyed and its memory made available for reuse.
SV to a mortal SV (and thus defers a call to C<SvREFCNT_dec>), and the
third creates a mortal copy of an existing SV.
Because C<sv_newmortal> gives the new SV no value,it must normally be given one
-via C<sv_setpv>, C<sv_setiv> etc. :
+via C<sv_setpv>, C<sv_setiv>, etc. :
SV *tmp = sv_newmortal();
sv_setiv(tmp, an_integer);
The C<name> and C<namlen> arguments are used to associate a string with
the magic, typically the name of a variable. C<namlen> is stored in the
-C<mg_len> field and if C<name> is non-null and C<namlen> >= 0 a malloc'd
+C<mg_len> field and if C<name> is non-null and C<namlen> E<gt>= 0 a malloc'd
copy of the name is stored in C<mg_ptr> field.
The sv_magic function uses C<how> to determine which, if any, predefined
from the set of macros C<PERL_MAGIC_foo> found perl.h. Note that before
these macros were added, Perl internals used to directly use character
literals, so you may occasionally come across old code or documentation
-referrring to 'U' magic rather than C<PERL_MAGIC_uvar> for example.
+referring to 'U' magic rather than C<PERL_MAGIC_uvar> for example.
The C<obj> argument is stored in the C<mg_obj> field of the C<MAGIC>
structure. If it is not the same as the C<sv> argument, the reference
=head2 Magic Virtual Tables
-The C<mg_virtual> field in the C<MAGIC> structure is a pointer to a
+The C<mg_virtual> field in the C<MAGIC> structure is a pointer to an
C<MGVTBL>, which is a structure of function pointers and stands for
"Magic Virtual Table" to handle the various operations that might be
applied to that variable.
Function pointer Action taken
---------------- ------------
- svt_get Do something after the value of the SV is retrieved.
+ svt_get Do something before the value of the SV is retrieved.
svt_set Do something after the SV is assigned a value.
svt_len Report on the SV's length.
svt_clear Clear something the SV represents.
aware that the behavior may change in the future, umm, without warning.
The perl tie function associates a variable with an object that implements
-the various GET, SET etc methods. To perform the equivalent of the perl
+the various GET, SET, etc methods. To perform the equivalent of the perl
tie function from an XSUB, you must mimic this behaviour. The code below
carries out the necessary steps - firstly it creates a new hash, and then
creates a second hash which it blesses into the class which will implement
The biggest difference is that the first construction would
reinstate the initial value of $var, irrespective of how control exits
-the block: C<goto>, C<return>, C<die>/C<eval> etc. It is a little bit
+the block: C<goto>, C<return>, C<die>/C<eval>, etc. It is a little bit
more efficient as well.
There is a way to achieve a similar task from C via Perl API: create a
=item C<SV* save_svref(SV **sptr)>
-Similar to C<save_scalar>, but will reinstate a C<SV *>.
+Similar to C<save_scalar>, but will reinstate an C<SV *>.
=item C<void save_aptr(AV **aptr)>
All four routines return the number of arguments that the subroutine returned
on the Perl stack.
-These routines used to be called C<perl_call_sv> etc., before Perl v5.6.0,
+These routines used to be called C<perl_call_sv>, etc., before Perl v5.6.0,
but those names are now deprecated; macros of the same name are provided for
compatibility.
(initially) one element, and this element is the scratchpad AV. Why do
we need an extra level of indirection?
-The answer is B<recursion>, and maybe (sometime soon) B<threads>. Both
+The answer is B<recursion>, and maybe B<threads>. Both
these can create several execution pointers going into the same
subroutine. For the subroutine-child not write over the temporaries
for the subroutine-parent (lifespan of which covers the call to the
module should already be familiar with its format.
C<Perl_op_dump> can be used to dump an C<OP> structure or any of its
-derivatives, and produces output similiar to C<perl -Dx>; in fact,
+derivatives, and produces output similar to C<perl -Dx>; in fact,
C<Perl_dump_eval> will dump the main root of the code being evaluated,
exactly like C<-Dx>.
for feeding it code or otherwise making it do things, but it also has
functions for its own use. This smells a lot like an object, and
there are ways for you to build Perl so that you can have multiple
-interpreters, with one interpreter represented either as a C++ object,
-a C structure, or inside a thread. The thread, the C structure, or
-the C++ object will contain all the context, the state of that
-interpreter.
-
-Three macros control the major Perl build flavors: MULTIPLICITY,
-USE_THREADS and PERL_OBJECT. The MULTIPLICITY build has a C structure
-that packages all the interpreter state, there is a similar thread-specific
-data structure under USE_THREADS, and the (now deprecated) PERL_OBJECT
-build has a C++ class to maintain interpreter state. In all three cases,
+interpreters, with one interpreter represented either as a C structure,
+or inside a thread-specific structure. These structures contain all
+the context, the state of that interpreter.
+
+Two macros control the major Perl build flavors: MULTIPLICITY and
+USE_5005THREADS. The MULTIPLICITY build has a C structure
+that packages all the interpreter state, and there is a similar thread-specific
+data structure under USE_5005THREADS. In both cases,
PERL_IMPLICIT_CONTEXT is also normally defined, and enables the
support for passing in a "hidden" first argument that represents all three
data structures.
All this obviously requires a way for the Perl internal functions to be
-C++ methods, subroutines taking some kind of structure as the first
+either subroutines taking some kind of structure as the first
argument, or subroutines taking nothing as the first argument. To
-enable these three very different ways of building the interpreter,
+enable these two very different ways of building the interpreter,
the Perl source (as it does in so many other situations) makes heavy
use of macros and subroutine naming conventions.
STATIC void
S_incline(pTHX_ char *s)
-STATIC becomes "static" in C, and is #define'd to nothing in C++.
+STATIC becomes "static" in C, and may be #define'd to nothing in some
+configurations in future.
A public function (i.e. part of the internal API, but not necessarily
sanctioned for use in extensions) begins like this:
and still have it work under all the modes Perl could have been
compiled with.
-Under PERL_OBJECT in the core, that will translate to either:
-
- CPerlObj::Perl_sv_setsv(foo,bar); # in CPerlObj functions,
- # C++ takes care of 'this'
- or
-
- pPerl->Perl_sv_setsv(foo,bar); # in truly static functions,
- # see objXSUB.h
-
-Under PERL_OBJECT in extensions (aka PERL_CAPI), or under
-MULTIPLICITY/USE_THREADS with PERL_IMPLICIT_CONTEXT in both core
-and extensions, it will become:
-
- Perl_sv_setsv(aTHX_ foo, bar); # the canonical Perl "API"
- # for all build flavors
-
This doesn't work so cleanly for varargs functions, though, as macros
imply that the number of arguments is known in advance. Instead we
either need to spell them out fully, passing C<aTHX_> as the first
compatibility at the expense of performance. (Passing an arg is
cheaper than grabbing it from thread-local storage.)
-You can ignore [pad]THX[xo] when browsing the Perl headers/sources.
+You can ignore [pad]THXx when browsing the Perl headers/sources.
Those are strictly for use within the core. Extensions and embedders
need only be aware of [pad]THX.
that the interpreter knows about itself and pass it around, so too are
there plans to allow the interpreter to bundle up everything it knows
about the environment it's running on. This is enabled with the
-PERL_IMPLICIT_SYS macro. Currently it only works with PERL_OBJECT
-and USE_THREADS on Windows (see inside iperlsys.h).
+PERL_IMPLICIT_SYS macro. Currently it only works with USE_ITHREADS
+and USE_5005THREADS on Windows (see inside iperlsys.h).
This allows the ability to provide an extra pointer (called the "host"
environment) for all the system calls. This makes it possible for
=head1 Custom Operators
-Custom operator support is a new experimental feature that allows you do
+Custom operator support is a new experimental feature that allows you to
define your own ops. This is primarily to allow the building of
interpreters for other languages in the Perl core, but it also allows
optimizations through the creation of "macro-ops" (ops which perform the
functions of multiple ops which are usually executed together, such as
-C<gvsv, gvsv, add>.) Currently, this feature must be enabled with the C
-flag C<-DPERL_CUSTOM_OPS>.
+C<gvsv, gvsv, add>.)
-Enabling the feature will create a new op type, C<OP_CUSTOM>. The Perl
+This feature is implemented as a new op type, C<OP_CUSTOM>. The Perl
core does not "know" anything special about this op type, and so it will
not be involved in any optimizations. This also means that you can
define your custom ops to be any op structure - unary, binary, list and
=head1 AUTHORS
Until May 1997, this document was maintained by Jeff Okamoto
-<okamoto@corp.hp.com>. It is now maintained as part of Perl itself
-by the Perl 5 Porters <perl5-porters@perl.org>.
+E<lt>okamoto@corp.hp.comE<gt>. It is now maintained as part of Perl
+itself by the Perl 5 Porters E<lt>perl5-porters@perl.orgE<gt>.
With lots of help and suggestions from Dean Roehrich, Malcolm Beattie,
Andreas Koenig, Paul Hudson, Ilya Zakharevich, Paul Marquess, Neil
Bowers, Matthew Green, Tim Bunce, Spider Boardman, Ulrich Pfeifer,
Stephen McCamant, and Gurusamy Sarathy.
-API Listing originally by Dean Roehrich <roehrich@cray.com>.
+API Listing originally by Dean Roehrich E<lt>roehrich@cray.comE<gt>.
Modifications to autogenerate the API listing (L<perlapi>) by Benjamin
Stuhl.