NAME
Inline::C - Write Perl Subroutines in C
DESCRIPTION
Inline::C
is a module that allows you to write Perl subroutines in C. Since version 0.30 the Inline
module supports multiple programming languages and eeach language has its own support module. This document describes how to use Inline
with the C programming language. It also goes a bit into Perl C internals.
If you want to start working with programming examples right away, check out Inline::C-Cookbook. For more information on Inline
in general, see Inline.
Usage
You never actually use Inline::C
directly. It is just a support module for using Inline.pm
with C. So the usage is always:
use Inline C => ...;
or
bind Inline C => ...;
Function Definitions
The Inline
grammar for C recognizes certain function definitions (or signatures) in your C code. If a signature is recognized by Inline
, then it will be available in Perl-space. That is, Inline
will generate the "glue" necessary to call that function as if it were a Perl subroutine. If the signature is not recognized, Inline
will simply ignore it, with no complaints. It will not be available from Perl-space, although it will be available from C-space.
Inline
looks for ANSI/prototype style function definitions. They must be of the form:
return-type function-name ( type-name-pairs ) { ... }
They also may only use the types: int
, long
, double
, char*
, and SV*
. A return type of void
may also be used. The following are examples of valid function definitions.
int Foo(double num, char* str) {
void Foo(double num, char* str) {
SV* Foo() {
void Foo(SV*, ...) {
long Foo(int i, int j, ...) {
The following definitions would not be recognized:
Foo(int i) { # no return type
unsigned int Foo(int i) { # 'unsigned int' not recognized
int Foo(num, str) double num; char* str; {
void Foo(void) { # void only valid for return type
Notice that Inline
only looks for function definitions, not function prototypes. Definitions are the syntax directly preceeding a function body. Also Inline
does not scan external files, like headers. Only the code passed to Inline
is used to create bindings; although other libraries can linked in, and called from C-space.
C Configuration Options
For information on how to specify Inline
configuration options, see Inline. This section describes each of the configuration options available for C. Most of the options correspond either to MakeMaker or XS options of the same name. See ExtUtils::MakeMaker and perlxs.
LIBS
Specifies external libraries that should be linked into your code. Corresponds to the MakeMaker parameter.
use C => Config => LIBS => '-lyourlib';
or
use C => Config => LIBS => '-L/your/path -lyourlib';
INC
Specifies an include path to use. Corresponds to the MakeMaker parameter.
use C => Config => INC => '-I/inc/path';
MYEXTLIB
Specifies a user compiled object that should be linked in. Corresponds to the MakeMaker parameter.
use C => Config => MYEXTLIB => '/your/path/yourmodule.so';
TYPEMAPS
Specifies extra typemap files to use. These types will modify the behaviour of the C parsing. Corresponds to the MakeMaker parameter.
use C => Config => TYPEMAPS => '/your/path/typemap';
AUTO_INCLUDE
Specifies extra statements to automatically included. They will be added onto the defaults. A newline char will be automatically added.
use C => Config => AUTO_INCLUDE => '#include "yourheader.h"';
BOOT
Specifies C code to be executed in the XS BOOT section. Corresponds to the XS parameter.
PREFIX
Specifies a prefix that will be automatically stripped from C functions when they are bound to Perl. Useful for creating wrappers for shared library API-s, and binding to the original names in Perl. Also useful when names conflict with Perl internals. Corresponds to the XS parameter.
use C => Config => PREFIX => 'ZLIB_';
C-Perl Bindings
This section describes how the Perl
variables get mapped to C
variables and back again.
First, you need to know how Perl
passes arguments back and forth to subroutines. Basically it uses a stack (also known as the Stack). When a sub is called, all of the parenthesized arguments get expanded into a list of scalars and pushed onto the Stack. The subroutine then pops all of its parameters off of the Stack. When the sub is done, it pushes all of its return values back onto the Stack.
The Stack is an array of scalars known internally as SV
's. The Stack is actually an array of pointers to SV or SV*
; therefore every element of the Stack is natively a SV*
. For FMTYEWTK about this, read perldoc perlguts
.
So back to variable mapping. XS uses a thing known as "typemaps" to turn each SV*
into a C
type and back again. This is done through various XS macro calls, casts and the Perl API. See perldoc perlapi
. XS allows you to define your own typemaps as well for fancier non-standard types such as typedef
-ed structs.
Inline
uses the default Perl typemap file for its default types. It parses your code for these types and generates the XS code to map them. The most commonly used types are:
- int
- long
- double
- char*
- void
- SV*
If you need to deal with anything fancier, just use the generic SV*
type in the function definition. Then inside your code, do the mapping yourself. Alternatively, you can create your own typemap files and specify them using the TYPEMAPS
configuration option.
A return type of void
has a special meaning to Inline
. It means that you plan to push the values back onto the Stack yourself. This is what you need to do to return a list of values. If you really don't want to return anything (the traditional meaning of void
) then simply don't push anything back.
If ellipsis or ...
is used at the end of an argument list, it means that any number of SV*
s may follow. Again you will need to pop the values off of the Stack
yourself.
See "Examples" below.
The Inline Stack Macros
When you write Inline
C, the following lines are automatically prepended to your code (by default):
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include "INLINE.h"
The file INLINE.h
defines a set of macros that are useful for handling the Perl Stack from your C functions.
- Inline_Stack_Vars
-
You'll need to use this one, if you want to use the others. It sets up a few local variables:
sp
,items
,ax
andmark
, for use by the other macros. It's not important to know what they do, but I mention them to avoid possible name conflicts. - Inline_Stack_Items
-
Returns the number of arguments passed in on the Stack.
- Inline_Stack_Item(i)
-
Refers to a particular
SV*
in the Stack, wherei
is an index number starting from zero. Can be used to get or set the value. - Inline_Stack_Reset
-
Use this before pushing anything back onto the Stack. It resets the internal Stack pointer to the beginning of the Stack.
- Inline_Stack_Push(sv)
-
Push a return value back onto the Stack. The value must be of type
SV*
. - Inline_Stack_Done
-
After you have pushed all of your return values, you must call this macro.
- Inline_Stack_Return(n)
-
Return
n
items on the Stack. - Inline_Stack_Void
-
A special macro to indicate that you really don't want to return anything. Same as:
Inline_Stack_Return(0);
Each of these macros is available in 3 different styles to suit your coding tastes. The following macros are equivalent.
Inline_Stack_Vars
inline_stack_vars
INLINE_STACK_VARS
All of this functionality is available through XS macro calls as well. So why duplicate the functionality? There are a few reasons why I decided to offer this set of macros. First, as a convenient way to access the Stack. Second, for consistent, self documenting, non-cryptic coding. Third, for future compatibility. It occured to me that if a lot of people started using XS macros for their C code, the interface might break under Perl6. By using this set, hopefully I will be able to insure future compatibility of argument handling.
Of course, if you use the rest of the Perl API, your code will most likely break under Perl6. So this is not a 100% guarantee. But since argument handling is the most common interface you're likely to use, it seemed like a wise thinng to do.
Writing C Subroutines
The definitions of your C functions will fall into one of the following four categories. For each category there are special considerations.
-
int Foo(int arg1, char* arg2, SV* arg3) {
This is the simplest case. You have a non
void
return type and a fixed length argument list. You don't need to worry about much. All the conversions will happen automatically. -
void Foo(int arg1, char* arg2, SV* arg3) {
In this category you have a
void
return type. This means that either you want to return nothing, or that you want to return a list. In the latter case you'll need to push values onto the Stack yourself. There are a fewInline
macros that make this easy. Code something like this:int i, max; SV* my_sv[10]; Inline_Stack_Vars; Inline_Stack_Reset; for (i = 0; i < max; i++) Inline_Stack_Push(my_sv[i]); Inline_Stack_Done;
After resetting the Stack pointer, this code pushes a series of return values. At the end it uses
Inline_Stack_Done
to mark the end of the return stack.If you really want to return nothing, then don't use the
Inline_Stack_
macros. If you must use them, then set useInline_Stack_Void
at the end of your function. -
char* Foo(SV* arg1, ...) {
In this category you have an unfixed number of arguments. This means that you'll have to pop values off the Stack yourself. Do it like this:
int i; Inline_Stack_Vars; for (i = 0; i < Inline_Stack_Items; i++) handle_sv(Inline_Stack_Item(i));
The return type of
Inline_Stack_Item(i)
isSV*
. -
void* Foo(SV* arg1, ...) {
In this category you have both a
void
return type and an unfixed number of arguments. Just combine the techniques from Categories 3 and 4.
Examples
Here is a few examples. Each one is a complete program that you can try running yourself. For many more examples see Inline::C-Cookbook.
Example #1 - Greetings
This example will take one string argument (a name) and print a greeting. The function is called with a string and with a number. In the second case the number is forced to a string.
Notice that you do not need to #include <stdio.h
>. The perl.h
header file which gets included by default, automatically loads the standard C header files for you.
greet('Ingy');
greet(42);
use Inline C => <<'END_OF_C_CODE';
void greet(char* name) {
printf("Hello %s!\n", name);
}
END_OF_C_CODE
Example #2 - and Salutations
This is similar to the last example except that the name is passed in as a SV*
(pointer to Scalar Value) rather than a string (char*
). That means we need to convert the SV
to a string ourselves. This is accomplished using the SvPVX
function which is part of the Perl
internal API. See perldoc perlapi
for more info.
One problem is that SvPVX
doesn't automatically convert strings to numbers, so we get a little surprise when we try to greet 42
. The program segfaults, a common occurence when delving into the guts of Perl.
greet('Ingy');
greet(42);
use Inline C => <<'END_OF_C_CODE';
void greet(SV* sv_name) {
printf("Hello %s!\n", SvPVX(sv_name));
}
END_OF_C_CODE
Example #3 - Fixing the problem
We can fix the problem in Example #2 by using the SvPV
function instead. This function will stringify the SV
if it does not contain a string. SvPV
returns the length of the string as it's second parameter. Since we don't care about the length, we can just put PL_na
there, which is a special variable designed for that purpose.
greet('Ingy');
greet(42);
use Inline C => <<'END_OF_C_CODE';
void greet(SV* sv_name) {
printf("Hello %s!\n", SvPV(sv_name, PL_na));
}
END_OF_C_CODE
SEE ALSO
For general information about Inline
see Inline.
For sample programs using Inline
with C see Inline::C-Cookbook.
For information on supported languages and platforms see Inline-Support.
For information on writing your own Inline
Language Support Module, see Inline-API.
Inline's mailing list is inline@perl.org
To subscribe, send email to inline-subscribe@perl.org
AUTHOR
Brian Ingerson <INGY@cpan.org>
COPYRIGHT
Copyright (c) 2000, Brian Ingerson. All Rights Reserved. This module is free software. It may be used, redistributed and/or modified under the terms of the Perl Artistic License.
See http://www.perl.com/perl/misc/Artistic.html