Each typedef has specific routines that manipulate the various data types.
-=for apidoc_section AV Handling
+=for apidoc_section $AV
=for apidoc Ayh||AV
-=for apidoc_section HV Handling
+=for apidoc_section $HV
=for apidoc Ayh||HV
-=for apidoc_section SV Handling
+=for apidoc_section $SV
=for apidoc Ayh||SV
=head2 What is an "IV"?
A numeric constant can be specified with L<perlapi/C<INT16_C>>,
L<perlapi/C<UINTMAX_C>>, and similar.
-=for apidoc_section Integer configuration values
+=for apidoc_section $integer
=for apidoc Ayh||I8
=for apidoc_item ||I16
=for apidoc_item ||I32
Nevertheless, you should be very careful when you pass a string stored
in an SV to a C function or system call.
-To access the actual value that an SV points to, you can use the macros:
+To access the actual value that an SV points to, Perl's API exposes
+several macros that coerce the actual scalar type into an IV, UV, double,
+or string:
- SvIV(SV*)
- SvUV(SV*)
- SvNV(SV*)
- SvPV(SV*, STRLEN len)
- SvPV_nolen(SV*)
+=over
+
+=item * C<SvIV(SV*)> (C<IV>) and C<SvUV(SV*)> (C<UV>)
+
+=item * C<SvNV(SV*)> (C<double>)
+
+=item * Strings are a bit complicated:
+
+=over
+
+=item * Byte string: C<SvPVbyte(SV*, STRLEN len)> or C<SvPVbyte_nolen(SV*)>
+
+If the Perl string is C<"\xff\xff">, then this returns a 2-byte C<char*>.
+
+This is suitable for Perl strings that represent bytes.
+
+=item * UTF-8 string: C<SvPVutf8(SV*, STRLEN len)> or C<SvPVutf8_nolen(SV*)>
+
+If the Perl string is C<"\xff\xff">, then this returns a 4-byte C<char*>.
+
+This is suitable for Perl strings that represent characters.
+
+B<CAVEAT>: That C<char*> will be encoded via Perl's internal UTF-8 variant,
+which means that if the SV contains non-Unicode code points (e.g.,
+0x110000), then the result may contain extensions over valid UTF-8.
+See L<perlapi/is_strict_utf8_string> for some methods Perl gives
+you to check the UTF-8 validity of these macros' returns.
+
+=item * You can also use C<SvPV(SV*, STRLEN len)> or C<SvPV_nolen(SV*)>
+to fetch the SV's raw internal buffer. This is tricky, though; if your Perl
+string
+is C<"\xff\xff">, then depending on the SV's internal encoding you might get
+back a 2-byte B<OR> a 4-byte C<char*>.
+Moreover, if it's the 4-byte string, that could come from either Perl
+C<"\xff\xff"> stored UTF-8 encoded, or Perl C<"\xc3\xbf\xc3\xbf"> stored
+as raw octets. To differentiate between these you B<MUST> look up the
+SV's UTF8 bit (cf. C<SvUTF8>) to know whether the source Perl string
+is 2 characters (C<SvUTF8> would be on) or 4 characters (C<SvUTF8> would be
+off).
+
+B<IMPORTANT:> Use of C<SvPV>, C<SvPV_nolen>, or
+similarly-named macros I<without> looking up the SV's UTF8 bit is
+almost certainly a bug if non-ASCII input is allowed.
-which will automatically coerce the actual scalar type into an IV, UV, double,
-or string.
+When the UTF8 bit is on, the same B<CAVEAT> about UTF-8 validity applies
+here as for C<SvPVutf8>.
-In the C<SvPV> macro, the length of the string returned is placed into the
-variable C<len> (this is a macro, so you do I<not> use C<&len>). If you do
-not care what the length of the data is, use the C<SvPV_nolen> macro.
-Historically the C<SvPV> macro with the global variable C<PL_na> has been
-used in this case. But that can be quite inefficient because C<PL_na> must
+=back
+
+(See L</How do I pass a Perl string to a C library?> for more details.)
+
+In C<SvPVbyte>, C<SvPVutf8>, and C<SvPV>, the length of the C<char*> returned
+is placed into the
+variable C<len> (these are macros, so you do I<not> use C<&len>). If you do
+not care what the length of the data is, use C<SvPVbyte_nolen>,
+C<SvPVutf8_nolen>, or C<SvPV_nolen> instead.
+The global variable C<PL_na> can also be given to
+C<SvPVbyte>/C<SvPVutf8>/C<SvPV>
+in this case. But that can be quite inefficient because C<PL_na> must
be accessed in thread-local storage in threaded Perl. In any case, remember
that Perl allows arbitrary strings of data that may both contain NULs and
might not be terminated by a C<NUL>.
-Also remember that C doesn't allow you to safely say C<foo(SvPV(s, len),
+Also remember that C doesn't allow you to safely say C<foo(SvPVbyte(s, len),
len);>. It might work with your
compiler, but it won't work for everyone.
Break this sort of statement up into separate assignments:
SV *s;
STRLEN len;
char *ptr;
- ptr = SvPV(s, len);
+ ptr = SvPVbyte(s, len);
foo(ptr, len);
+=back
+
If you want to know if the scalar value is TRUE, you can use:
SvTRUE(SV*)
C<SvGROW(sv, len + 1)>).
If you want to write to an existing SV's buffer and set its value to a
-string, use SvPV_force() or one of its variants to force the SV to be
+string, use SvPVbyte_force() or one of its variants to force the SV to be
a PV. This will remove any of various types of non-stringness from
the SV while preserving the content of the SV in the PV. This can be
used, for example, to append data from an API function to a buffer
See L</Understanding the Magic of Tied Hashes and Arrays> for more
information on how to use the hash access functions on tied hashes.
-=for apidoc_section HV Handling
+=for apidoc_section $HV
=for apidoc Amh|void|PERL_HASH|U32 hash|char *key|STRLEN klen
=head2 Hash API Extensions
For more information on references and blessings, consult L<perlref>.
+=head2 I/O Handles
+
+Like AVs and HVs, IO objects are another type of non-scalar SV which
+may contain input and output L<PerlIO|perlapio> objects or a C<DIR *>
+from opendir().
+
+You can create a new IO object:
+
+ IO* newIO();
+
+Unlike other SVs, a new IO object is automatically blessed into the
+L<IO::File> class.
+
+The IO object contains an input and output PerlIO handle:
+
+ PerlIO *IoIFP(IO *io);
+ PerlIO *IoOFP(IO *io);
+
+Typically if the IO object has been opened on a file, the input handle
+is always present, but the output handle is only present if the file
+is open for output. For a file, if both are present they will be the
+same PerlIO object.
+
+Distinct input and output PerlIO objects are created for sockets and
+character devices.
+
+The IO object also contains other data associated with Perl I/O
+handles:
+
+ IV IoLINES(io); /* $. */
+ IV IoPAGE(io); /* $% */
+ IV IoPAGE_LEN(io); /* $= */
+ IV IoLINES_LEFT(io); /* $- */
+ char *IoTOP_NAME(io); /* $^ */
+ GV *IoTOP_GV(io); /* $^ */
+ char *IoFMT_NAME(io); /* $~ */
+ GV *IoFMT_GV(io); /* $~ */
+ char *IoBOTTOM_NAME(io);
+ GV *IoBOTTOM_GV(io);
+ char IoTYPE(io);
+ U8 IoFLAGS(io);
+
+Most of these are involved with L<formats|perlform>.
+
+IoFLAGs() may contain a combination of flags, the most interesting of
+which are C<IOf_FLUSH> (C<$|>) for autoflush and C<IOf_UNTAINT>,
+settable with L<< IO::Handle's untaint() method|IO::Handle/"$io->untaint" >>.
+
+The IO object may also contains a directory handle:
+
+ DIR *IoDIRP(io);
+
+suitable for use with PerlDir_read() etc.
+
+All of these accessors macros are lvalues, there are no distinct
+C<_set()> macros to modify the members of the IO object.
+
=head2 Double-Typed SVs
Scalar variables normally contain only one type of value, an integer,
These macros arrange things to restore the value of integer variable
C<i> at the end of the enclosing I<pseudo-block>.
-=for apidoc_section Stack Manipulation Macros
+=for apidoc_section $stack
=for apidoc Amh||SAVEINT|int i
=for apidoc Amh||SAVEIV|IV i
=for apidoc Amh||SAVEI32|I32 i
=for apidoc Amh||SAVELONG|long i
=for apidoc Amh||SAVEI8|I8 i
=for apidoc Amh||SAVEI16|I16 i
-=for apidoc Amh||SAVEBOOL|int i
+=for apidoc Amh||SAVEBOOL|bool i
=item C<SAVESPTR(s)>
PL_runops = my_runops;
+=for apidoc Amnh|runops_proc_t|PL_runops
+
This function should be as efficient as possible to keep your programs
running as fast as possible.
STATIC becomes "static" in C, and may be #define'd to nothing in some
configurations in the future.
-=for apidoc_section Compiler directives
+=for apidoc_section $directives
=for apidoc Ayh||STATIC
A public function (i.e. part of the internal API, but not necessarily
or 'd' for B<d>eclaration, so we have C<pTHX>, C<aTHX> and C<dTHX>, and
their variants.
-=for apidoc_section Concurrency
+=for apidoc_section $concurrency
=for apidoc Amnh||aTHX
=for apidoc Amnh||aTHX_
=for apidoc Amnh||dTHX
The contents of SVs may be printed using the C<SVf> format, like so:
- Perl_croak(aTHX_ "This croaked because: %" SVf "\n", SvfARG(err_msg))
+ Perl_croak(aTHX_ "This croaked because: %" SVf "\n", SVfARG(err_msg))
where C<err_msg> is an SV.
One way to do this for typical filehandles is to invoke perl with the
C<-C>> parameter. (See L<perlrun/-C [numberE<sol>list]>.
-=for apidoc_section Formats
+=for apidoc_section $formats
=for apidoc Amnh||UTF8f
=for apidoc Amh||UTF8fARG|bool is_utf8|Size_t byte_len|char *str
PTR2NV(pointer)
INT2PTR(pointertotype, integer)
-=for apidoc_section Casting
+=for apidoc_section $casting
=for apidoc Amh|type|INT2PTR|type|int value
=for apidoc Amh|UV|PTR2UV|void * ptr
=for apidoc Amh|IV|PTR2IV|void * ptr
change, but you can look at the code for C<pp_lc> in F<pp.c> for an
example as to how it's currently done.
+=head2 How do I pass a Perl string to a C library?
+
+A Perl string, conceptually, is an opaque sequence of code points.
+Many C libraries expect their inputs to be "classical" C strings, which are
+arrays of octets 1-255, terminated with a NUL byte. Your job when writing
+an interface between Perl and a C library is to define the mapping between
+Perl and that library.
+
+Generally speaking, C<SvPVbyte> and related macros suit this task well.
+These assume that your Perl string is a "byte string", i.e., is either
+raw, undecoded input into Perl or is pre-encoded to, e.g., UTF-8.
+
+Alternatively, if your C library expects UTF-8 text, you can use
+C<SvPVutf8> and related macros. This has the same effect as encoding
+to UTF-8 then calling the corresponding C<SvPVbyte>-related macro.
+
+Some C libraries may expect other encodings (e.g., UTF-16LE). To give
+Perl strings to such libraries
+you must either do that encoding in Perl then use C<SvPVbyte>, or
+use an intermediary C library to convert from however Perl stores the
+string to the desired encoding.
+
+Take care also that NULs in your Perl string don't confuse the C
+library. If possible, give the string's length to the C library; if that's
+not possible, consider rejecting strings that contain NUL bytes.
+
+=head3 What about C<SvPV>, C<SvPV_nolen>, etc.?
+
+Consider a 3-character Perl string C<$foo = "\x64\x78\x8c">.
+Perl can store these 3 characters either of two ways:
+
+=over
+
+=item * bytes: 0x64 0x78 0x8c
+
+=item * UTF-8: 0x64 0x78 0xc2 0x8c
+
+=back
+
+Now let's say you convert C<$foo> to a C string thus:
+
+ STRLEN strlen;
+ char *str = SvPV(foo_sv, strlen);
+
+At this point C<str> could point to a 3-byte C string or a 4-byte one.
+
+Generally speaking, we want C<str> to be the same regardless of how
+Perl stores C<$foo>, so the ambiguity here is undesirable. C<SvPVbyte>
+and C<SvPVutf8> solve that by giving predictable output: use
+C<SvPVbyte> if your C library expects byte strings, or C<SvPVutf8>
+if it expects UTF-8.
+
+If your C library happens to support both encodings, then C<SvPV>--always
+in tandem with lookups to C<SvUTF8>!--may be safe and (slightly) more
+efficient.
+
+B<TESTING> B<TIP:> Use L<utf8>'s C<upgrade> and C<downgrade> functions
+in your tests to ensure consistent handling regardless of Perl's
+internal encoding.
+
=head2 How do I convert a string to UTF-8?
If you're mixing UTF-8 and non-UTF-8 strings, it is necessary to upgrade
address to the temporaries stack.
Likewise, there is no public API to read values from the temporaries stack.
-Instead. the macros C<SAVETMPS> and C<FREETPMS> are used. The C<SAVETMPS>
+Instead, the macros C<SAVETMPS> and C<FREETMPS> are used. The C<SAVETMPS>
macro establishes the base levels of the temporaries stack, by capturing the
current value of C<PL_tmps_ix> into C<PL_tmps_floor> and saving the previous
value to the save stack. Thereafter, whenever C<FREETMPS> is invoked all of
https://perl5.git.perl.org / perl5.git / blobdiff