HE* hv_fetch_ent (HV* tb, SV* key, I32 lval, U32 hash);
HE* hv_store_ent (HV* tb, SV* key, SV* val, U32 hash);
-
+
bool hv_exists_ent (HV* tb, SV* key, U32 hash);
SV* hv_delete_ent (HV* tb, SV* key, I32 flags, U32 hash);
-
+
SV* hv_iterkeysv (HE* entry);
Note that these functions take C<SV*> keys, which simplifies writing
They also return and accept whole hash entries (C<HE*>), making their
use more efficient (since the hash number for a particular string
-doesn't have to be recomputed every time). See L<API LISTING> later in
-this document for detailed descriptions.
+doesn't have to be recomputed every time). See L<perlapi> for detailed
+descriptions.
The following macros must always be used to access the contents of hash
entries. Note that the arguments to these macros must be simple
variables, since they may get evaluated more than once. See
-L<API LISTING> later in this document for detailed descriptions of these
-macros.
+L<perlapi> for detailed descriptions of these macros.
HePV(HE* he, STRLEN len)
HeVAL(HE* he)
C<sv_cat*_mg()> functions. Similarly, generic C code must call the
C<SvGETMAGIC()> macro to invoke any 'get' magic if they use an SV
obtained from external sources in functions that don't handle magic.
-L<API LISTING> later in this document identifies such functions.
+See L<perlapi> for a description of these functions.
For example, calls to the C<sv_cat*()> functions typically need to be
followed by C<SvSETMAGIC()>, but they don't need a prior C<SvGETMAGIC()>
since their implementation handles 'get' magic.
=head2 Compile pass 1: check routines
-The tree is created by the I<pseudo-compiler> while yacc code feeds it
-the constructions it recognizes. Since yacc works bottom-up, so does
+The tree is created by the compiler while I<yacc> code feeds it
+the constructions it recognizes. Since I<yacc> works bottom-up, so does
the first pass of perl compilation.
What makes this pass interesting for perl developers is that some
optimization may be performed on this pass. This is optimization by
-so-called I<check routines>. The correspondence between node names
+so-called "check routines". The correspondence between node names
and corresponding check routines is described in F<opcode.pl> (do not
forget to run C<make regen_headers> if you modify this file).
=head1 How multiple interpreters and concurrency are supported
-WARNING: This information is subject to radical changes prior to
-the Perl 5.6 release. Use with caution.
-
=head2 Background and PERL_IMPLICIT_CONTEXT
The Perl interpreter can be regarded as a closed box: it has an API
"Perl_", but just because a function begins with "Perl_" does not mean it is
part of the API. The easiest way to be B<sure> a function is part of the API
is to find its entry in L<perlapi>. If it exists in L<perlapi>, it's part
-of the API. If it doesn't, and you think it should be (i.e., you need it fo
-r your extension), send mail via L<perlbug> explaining why you think it
+of the API. If it doesn't, and you think it should be (i.e., you need it for
+your extension), send mail via L<perlbug> explaining why you think it
should be.
(L<perlapi> itself is generated by embed.pl, a Perl script that generates
sv_setsv(asv, bsv);
-in your extesion will translate to this when PERL_IMPLICIT_CONTEXT is
+in your extension will translate to this when PERL_IMPLICIT_CONTEXT is
in effect:
Perl_sv_setsv(Perl_get_context(), asv, bsv);