CONTENTS

• NAME
• DESCRIPTION
  • Introduction
  • On The Road
  • The Anatomy of an XSUB
  • The Argument Stack
  • The RETVAL Variable
  • Returning SVs, AVs and HVs through RETVAL
  • The MODULE Keyword
  • The PACKAGE Keyword
  • The PREFIX Keyword
  • The OUTPUT: Keyword
  • The NO_OUTPUT Keyword
  • The CODE: Keyword
  • The INIT: Keyword
  • The NO_INIT Keyword
  • The TYPEMAP: Keyword
  • Initializing Function Parameters
  • Default Parameter Values
  • The PREINIT: Keyword
  • The SCOPE: Keyword
  • The INPUT: Keyword
  • The IN/OUTLIST/IN_OUTLIST/OUT/IN_OUT Keywords
  • The length(NAME) Keyword
  • Variable-length Parameter Lists
  • The C_ARGS: Keyword
  • The PPCODE: Keyword
  • Returning Undef And Empty Lists
  • The REQUIRE: Keyword
  • The CLEANUP: Keyword
  • The POSTCALL: Keyword
  • The BOOT: Keyword
  • The VERSIONCHECK: Keyword
  • The PROTOTYPES: Keyword
  • The PROTOTYPE: Keyword
  • The ALIAS: Keyword
  • The OVERLOAD: Keyword
  • The FALLBACK: Keyword
  • The INTERFACE: Keyword
  • The INTERFACE_MACRO: Keyword
  • The INCLUDE: Keyword
  • The INCLUDE_COMMAND: Keyword
  • The CASE: Keyword
  • The EXPORT_XSUB_SYMBOLS: Keyword
  • The & Unary Operator
  • Inserting POD, Comments and C Preprocessor Directives
  • Using XS With C++
  • Interface Strategy
  • Perl Objects And C Structures
  • Safely Storing Static Data in XS
    • MY_CXT REFERENCE
  • Thread-aware system interfaces
• EXAMPLES
• CAVEATS
• XS VERSION
• AUTHOR

#NAME

perlxs - XS language reference manual

#DESCRIPTION

#Introduction

XS is an interface description file format used to create an extension interface between Perl and C code (or a C library) which one wishes to use with Perl. The XS interface is combined with the library to create a new library which can then be either dynamically loaded or statically linked into perl. The XS interface description is written in the XS language and is the core component of the Perl extension interface.

Before writing XS, read the "CAVEATS" section below.

An XSUB forms the basic unit of the XS interface. After compilation by the xsubpp compiler, each XSUB amounts to a C function definition which will provide the glue between Perl calling conventions and C calling conventions.

The glue code pulls the arguments from the Perl stack, converts these Perl values to the formats expected by a C function, call this C function, transfers the return values of the C function back to Perl. Return values here may be a conventional C return value or any C function arguments that may serve as output parameters. These return values may be passed back to Perl either by putting them on the Perl stack, or by modifying the arguments supplied from the Perl side.

The above is a somewhat simplified view of what really happens. Since Perl allows more flexible calling conventions than C, XSUBs may do much more in practice, such as checking input parameters for validity, throwing exceptions (or returning undef/empty list) if the return value from the C function indicates failure, calling different C functions based on numbers and types of the arguments, providing an object-oriented interface, etc.

Of course, one could write such glue code directly in C. However, this would be a tedious task, especially if one needs to write glue for multiple C functions, and/or one is not familiar enough with the Perl stack discipline and other such arcana. XS comes to the rescue here: instead of writing this glue C code in long-hand, one can write a more concise short-hand description of what should be done by the glue, and let the XS compiler xsubpp handle the rest.

The XS language allows one to describe the mapping between how the C routine is used, and how the corresponding Perl routine is used. It also allows creation of Perl routines which are directly translated to C code and which are not related to a pre-existing C function. In cases when the C interface coincides with the Perl interface, the XSUB declaration is almost identical to a declaration of a C function (in K&R style). In such circumstances, there is another tool called h2xs that is able to translate an entire C header file into a corresponding XS file that will provide glue to the functions/macros described in the header file.

The XS compiler is called xsubpp. This compiler creates the constructs necessary to let an XSUB manipulate Perl values, and creates the glue necessary to let Perl call the XSUB. The compiler uses typemaps to determine how to map C function parameters and output values to Perl values and back. The default typemap (which comes with Perl) handles many common C types. A supplementary typemap may also be needed to handle any special structures and types for the library being linked. For more information on typemaps, see perlxstypemap.

A file in XS format starts with a C language section which goes until the first MODULE = directive. Other XS directives and XSUB definitions may follow this line. The "language" used in this part of the file is usually referred to as the XS language. xsubpp recognizes and skips POD (see perlpod) in both the C and XS language sections, which allows the XS file to contain embedded documentation.

See perlxstut for a tutorial on the whole extension creation process.

Note: For some extensions, Dave Beazley's SWIG system may provide a significantly more convenient mechanism for creating the extension glue code. See http://www.swig.org/ for more information.

#On The Road

Many of the examples which follow will concentrate on creating an interface between Perl and the ONC+ RPC bind library functions. The rpcb_gettime() function is used to demonstrate many features of the XS language. This function has two parameters; the first is an input parameter and the second is an output parameter. The function also returns a status value.

bool_t rpcb_gettime(const char *host, time_t *timep);

From C this function will be called with the following statements.

#include <rpc/rpc.h>
bool_t status;
time_t timep;
status = rpcb_gettime( "localhost", &timep );

If an XSUB is created to offer a direct translation between this function and Perl, then this XSUB will be used from Perl with the following code. The $status and $timep variables will contain the output of the function.

use RPC;
$status = rpcb_gettime( "localhost", $timep );

The following XS file shows an XS subroutine, or XSUB, which demonstrates one possible interface to the rpcb_gettime() function. This XSUB represents a direct translation between C and Perl and so preserves the interface even from Perl. This XSUB will be invoked from Perl with the usage shown above. Note that the first three #include statements, for EXTERN.h, perl.h, and XSUB.h, will always be present at the beginning of an XS file. This approach and others will be expanded later in this document. A #define for PERL_NO_GET_CONTEXT should be present to fetch the interpreter context more efficiently, see perlguts for details.

#define PERL_NO_GET_CONTEXT
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include <rpc/rpc.h>

MODULE = RPC  PACKAGE = RPC

bool_t
rpcb_gettime(host,timep)
     char *host
     time_t &timep
   OUTPUT:
     timep

Any extension to Perl, including those containing XSUBs, should have a Perl module to serve as the bootstrap which pulls the extension into Perl. This module will export the extension's functions and variables to the Perl program and will cause the extension's XSUBs to be linked into Perl. The following module will be used for most of the examples in this document and should be used from Perl with the use command as shown earlier. Perl modules are explained in more detail later in this document.

package RPC;

require Exporter;
require DynaLoader;
@ISA = qw(Exporter DynaLoader);
@EXPORT = qw( rpcb_gettime );

bootstrap RPC;
1;

Throughout this document a variety of interfaces to the rpcb_gettime() XSUB will be explored. The XSUBs will take their parameters in different orders or will take different numbers of parameters. In each case the XSUB is an abstraction between Perl and the real C rpcb_gettime() function, and the XSUB must always ensure that the real rpcb_gettime() function is called with the correct parameters. This abstraction will allow the programmer to create a more Perl-like interface to the C function.