/usr/share/perl5/Inline/C.pod is in libinline-c-perl 0.76-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 | =pod
=for comment
DO NOT EDIT. This Pod was generated by Swim v0.1.39.
See http://github.com/ingydotnet/swim-pm#readme
=encoding utf8
=head1 NAME
Inline::C - C Language Support for Inline
=for html
<a href="https://travis-ci.org/ingydotnet/inline-c-pm"><img src="https://travis-ci.org/ingydotnet/inline-c-pm.png" alt="inline-c-pm"></a>
=head1 VERSION
This document describes L<Inline::C> version B<0.76>.
=head1 DESCRIPTION
C<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
each 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
L<Inline::C::Cookbook>. For more information on Inline in general, see
L<Inline>.
=head1 USAGE
You never actually use C<Inline::C> directly. It is just a support module for
using C<Inline.pm> with C. So the usage is always:
use Inline C => ...;
or
bind Inline C => ...;
=head1 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 I<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 ) { ... }
The most common types are: C<int>, C<long>, C<double>, C<char*>, and C<SV*>.
But you can use any type for which Inline can find a typemap. Inline uses the
C<typemap> file distributed with Perl as the default. You can specify more
typemaps with the C<typemaps> configuration option.
A return type of C<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) {
void Foo(SV*, ...) {
long Foo(int i, int j, ...) {
SV* Foo(void) { # 'void' arg invalid with the ParseRecDescent parser.
# Works only with the ParseRegExp parser.
# See the section on `using` (below).
SV* Foo() { # Alternative to specifying 'void' arg. Is valid with
# both the ParseRecDescent and ParseRegExp parsers.
The following definitions would not be recognized:
Foo(int i) { # no return type
int Foo(float f) { # no (default) typemap for float
int Foo(num, str) double num; char* str; {
Notice that Inline only looks for function I<definitions>, not function
I<prototypes>. Definitions are the syntax directly preceding 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.
=head1 C CONFIGURATION OPTIONS
For information on how to specify Inline configuration options, see L<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 L<ExtUtils::MakeMaker> and L<perlxs>.
=over
=item C<auto_include>
Specifies extra statements to automatically included. They will be added onto
the defaults. A newline char will be automatically added.
use Inline C => config => auto_include => '#include "yourheader.h"';
=item C<autowrap>
If you C<< enable => autowrap >>, Inline::C will parse function declarations
(prototype statements) in your C code. For each declaration it can bind to, it
will create a dummy wrapper that will call the real function which may be in
an external library. This is a nice convenience for functions that would
otherwise just require an empty wrapper function.
This is similar to the base functionality you get from C<h2xs>. It can be very
useful for binding to external libraries.
=item C<boot>
Specifies C code to be executed in the XS C<BOOT> section. Corresponds to the
XS parameter.
=item C<cc>
Specify which compiler to use.
=item C<ccflags>
Specify compiler flags - same as ExtUtils::MakeMaker's C<CCFLAGS> option.
Whatever gets specified here replaces the default C<$Config{ccflags}>. Often,
you'll want to add an extra flag or two without clobbering the default flags
in which case you could instead use C<ccflagsex> (see below) or, if Config.pm
has already been loaded:
use Inline C => Config => ccflags => $Config{ccflags} . " -DXTRA -DTOO";
=item C<ccflagsex>
Extend compiler flags. Sets C<CCFLAGS> to $Config{ccflags} followed by a
space, followed by the specified value:
use Inline C => config => ccflagsex => "-DXTRA -DTOO";
=item C<cppflags>
=back
Specify preprocessor flags. Passed to C<cpp> C preprocessor by C<Preprocess()>
in L<Inline::Filters>.
use Inline C => <<'END',
CPPFLAGS => ' -DPREPROCESSOR_DEFINE',
FILTERS => 'Preprocess';
use Inline C => <<'END',
CPPFLAGS => ' -DPREPROCESSOR_DEFINE=4321',
FILTERS => 'Preprocess';
=over
=item C<filters>
Allows you to specify a list of source code filters. If more than one is
requested, be sure to group them with an array ref. The filters can either be
subroutine references or names of filters provided by the supplementary
Inline::Filters module.
Your source code will be filtered just before it is parsed by Inline. The MD5
fingerprint is generated before filtering. Source code filters can be used to
do things like stripping out POD documentation, pre-expanding C<#include>
statements or whatever else you please. For example:
use Inline C => DATA =>
filters => [Strip_POD => \&MyFilter => Preprocess ];
Filters are invoked in the order specified. See L<Inline::Filters> for more
information.
If a filter is an array reference, it is assumed to be a usage of a filter plug-
in named by the first element of that array reference. The rest of the
elements of the array reference are used as arguments to the filter. For
example, consider a C<filters> parameter like this:
use Inline C => DATA => filters => [ [ Ragel => '-G2' ] ];
In order for Inline::C to process this filter, it will attempt to require the
module L<Inline::Filters::Ragel> and will then call the C<filter> function in
that package with the argument C<'-G2'>. This function will return the actual
filtering function.
=item C<inc>
Specifies an include path to use. Corresponds to the MakeMaker parameter.
Expects a fully qualified path.
use Inline C => config => inc => '-I/inc/path';
=item C<ld>
Specify which linker to use.
=item C<lddlflags>
Specify which linker flags to use.
NOTE: These flags will completely override the existing flags, instead of
just adding to them. So if you need to use those too, you must
respecify them here.
=item C<libs>
Specifies external libraries that should be linked into your code. Corresponds
to the MakeMaker parameter. Provide a fully qualified path with the C<-L>
switch if the library is in a location where it won't be found automatically.
use Inline C => config => libs => '-lyourlib';
or
use Inline C => config => libs => '-L/your/path -lyourlib';
=item C<make>
Specify the name of the 'make' utility to use.
=item C<myextlib>
Specifies a user compiled object that should be linked in. Corresponds to the
MakeMaker parameter. Expects a fully qualified path.
use Inline C => config => myextlib => '/your/path/yourmodule.so';
=item C<optimize>
This controls the MakeMaker C<OPTIMIZE> setting. By setting this value to
C<'-g'>, you can turn on debugging support for your Inline extensions. This
will allow you to be able to set breakpoints in your C code using a
debugger like gdb.
=item C<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 Inline C => config => prefix => 'ZLIB_';
=item C<pre_head>
Specifies code that will precede the inclusion of all files specified in
C<auto_include> (ie C<EXTERN.h>, C<perl.h>, C<XSUB.h>, C<INLINE.h> and
anything else that might have been added to C<auto_include> by the user). If
the specified value identifies a file, the contents of that file will be
inserted, otherwise the specified value is inserted.
use Inline C => config => pre_head => $code_or_filename;
=item C<prototype>
Corresponds to the XS keyword 'PROTOTYPE'. See the perlxs documentation for
both 'PROTOTYPES' and 'PROTOTYPE'. As an example, the following will set the
PROTOTYPE of the 'foo' function to '$', and disable prototyping for the
'bar' function.
use Inline C => config => prototype => {foo => '$', bar => 'DISABLE'}
=item C<prototypes>
Corresponds to the XS keyword 'PROTOTYPES'. Can take only values of 'ENABLE'
or 'DISABLE'. (Contrary to XS, default value is 'DISABLE'). See the perlxs
documentation for both 'PROTOTYPES' and 'PROTOTYPE'.
use Inline C => config => prototypes => 'ENABLE';
=item C<typemaps>
Specifies extra typemap files to use. These types will modify the behaviour of
the C parsing. Corresponds to the MakeMaker parameter. Specify either a fully
qualified path or a path relative to the cwd (ie relative to what the cwd is
at the time the script is loaded).
use Inline C => config => typemaps => '/your/path/typemap';
=item C<using>
Specifies which parser to use. The default is
L<Inline::C::Parser::RecDescent>, which uses the L<Parse::RecDescent> module.
The other options are C<::Parser::Pegex> and C<::Parser::RegExp>, which uses
the L<Inline::C::Parser::Pegex> and L<Inline::C::Parser::RegExp> modules that
ship with L<Inline::C>.
use Inline C => config => using => '::Parser::Pegex';
Note that the following old options are deprecated, but still work at
this time:
=over
=item * C<ParseRecDescent>
=item * C<ParseRegExp>
=item * C<ParsePegex>
=back
=back
=head1 C-PERL BINDINGS
This section describes how the C<Perl> variables get mapped to C<C> variables
and back again.
First, you need to know how C<Perl> passes arguments back and forth to
subroutines. Basically it uses a stack (also known as the B<Stack>). When a
sub is called, all of the parenthesized arguments get expanded into a list of
scalars and pushed onto the B<Stack>. The subroutine then pops all of its
parameters off of the B<Stack>. When the sub is done, it pushes all of its
return values back onto the B<Stack>.
The B<Stack> is an array of scalars known internally as C<SV>'s. The B<Stack>
is actually an array of B<pointers to SV> or C<SV*>; therefore every element
of the B<Stack> is natively a C<SV*>. For I<FMTYEWTK> about this, read
C<perldoc perlguts>.
So back to variable mapping. XS uses a thing known as "typemaps" to turn each
C<SV*> into a C<C> type and back again. This is done through various XS macro
calls, casts and the Perl API. See C<perldoc perlapi>. XS allows you to
define your own typemaps as well for fancier non-standard types such as C<typedef>-
ed structs.
Inline uses the default Perl typemap file for its default types. This file is
called C</usr/local/lib/perl5/5.6.1/ExtUtils/typemap>, or something similar,
depending on your Perl installation. It has definitions for over 40 types,
which are automatically used by Inline. (You should probably browse this file
at least once, just to get an idea of the possibilities.)
Inline parses your code for these types and generates the XS code to map them.
The most commonly used types are:
=over
=item * C<int>
=item * C<long>
=item * C<double>
=item * C<char*>
=item * C<void>
=item * C<SV*>
=back
If you need to deal with a type that is not in the defaults, just use the
generic C<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 C<typemaps> configuration option.
A return type of C<void> has a special meaning to Inline. It means that you
plan to push the values back onto the B<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 C<void>) then simply don't push anything back.
If ellipsis or C<...> is used at the end of an argument list, it means that
any number of C<SV*>s may follow. Again you will need to pop the values off of
the C<Stack> yourself.
See L<"Examples"> below.
=head1 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 C<INLINE.h> defines a set of macros that are useful for handling the
Perl Stack from your C functions.
=over
=item C<Inline_Stack_Vars>
You'll need to use this one, if you want to use the others. It sets up a few
local variables: C<sp>, C<items>, C<ax> and C<mark>, for use by the other
macros. It's not important to know what they do, but I mention them to avoid
possible name conflicts.
NOTE: Since this macro declares variables, you'll need to put it with your
other variable declarations at the top of your function. It must
come before any executable statements and before any other
C<Inline_Stack> macros.
=item C<Inline_Stack_Items>
Returns the number of arguments passed in on the Stack.
=item C<Inline_Stack_Item(i)>
Refers to a particular C<SV*> in the Stack, where C<i> is an index number
starting from zero. Can be used to get or set the value.
=item C<Inline_Stack_Reset>
Use this before pushing anything back onto the Stack. It resets the internal
Stack pointer to the beginning of the Stack.
=item C<Inline_Stack_Push(sv)>
Push a return value back onto the Stack. The value must be of type C<SV*>.
=item C<Inline_Stack_Done>
After you have pushed all of your return values, you must call this macro.
=item C<Inline_Stack_Return(n)>
Return C<n> items on the Stack.
=item C<Inline_Stack_Void>
A special macro to indicate that you really don't want to return
anything. Same as:
Inline_Stack_Return(0);
Please note that this macro actually B<returns> from your function.
=back
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 occurred 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 thing to do.
=head1 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.
=over
=item C<int Foo(int arg1, char* arg2, SV* arg3) {>
This is the simplest case. You have a non C<void> return type and a fixed
length argument list. You don't need to worry about much. All the conversions
will happen automatically.
=item C<void Foo(int arg1, char* arg2, SV* arg3) {>
In this category you have a C<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 B<Stack> yourself. There are a few Inline
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 C<Inline_Stack_Done> to mark the end of the return stack.
If you really want to return nothing, then don't use the C<Inline_Stack_>
macros. If you must use them, then set use C<Inline_Stack_Void> at the end of
your function.
=item C<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 B<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 C<Inline_Stack_Item(i)> is C<SV*>.
=item C<void* Foo(SV* arg1, ...) {>
In this category you have both a C<void> return type and an unfixed number of
arguments. Just combine the techniques from Categories 3 and 4.
=back
=head1 EXAMPLES
Here are a few examples. Each one is a complete program that you can try
running yourself. For many more examples see L<Inline::C::Cookbook>.
=head2 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 C<< #include <stdio.h >>>. The C<perl.h> header
file which gets included by default, automatically loads the standard C header
files for you.
use Inline C;
greet('Ingy');
greet(42);
__END__
__C__
void greet(char* name) {
printf("Hello %s!\n", name);
}
=head2 Example #2 - and Salutations
This is similar to the last example except that the name is passed in as a
C<SV*> (pointer to Scalar Value) rather than a string (C<char*>). That means
we need to convert the C<SV> to a string ourselves. This is accomplished using
the C<SvPVX> function which is part of the C<Perl> internal API. See C<perldoc
perlapi> for more info.
One problem is that C<SvPVX> doesn't automatically convert strings to numbers,
so we get a little surprise when we try to greet C<42>. The program segfaults,
a common occurrence when delving into the guts of Perl.
use Inline C;
greet('Ingy');
greet(42);
__END__
__C__
void greet(SV* sv_name) {
printf("Hello %s!\n", SvPVX(sv_name));
}
=head2 Example #3 - Fixing the problem
We can fix the problem in Example #2 by using the C<SvPV> function instead.
This function will stringify the C<SV> if it does not contain a string.
C<SvPV> returns the length of the string as it's second parameter. Since we
don't care about the length, we can just put C<PL_na> there, which is a
special variable designed for that purpose.
use Inline C;
greet('Ingy');
greet(42);
__END__
__C__
void greet(SV* sv_name) {
printf("Hello %s!\n", SvPV(sv_name, PL_na));
}
=head1 SEE ALSO
For general information about Inline see L<Inline>.
For sample programs using Inline with C see L<Inline::C::Cookbook>.
For information on supported languages and platforms see L<Inline-Support>.
For information on writing your own Inline Language Support Module, see
L<Inline-API>.
Inline's mailing list is inline@perl.org
To subscribe, send email to inline-subscribe@perl.org
=head1 BUGS AND DEFICIENCIES
If you use C function names that happen to be used internally by Perl, you
will get a load error at run time. There is currently no functionality to
prevent this or to warn you. For now, a list of Perl's internal symbols is
packaged in the Inline module distribution under the filename
C<'symbols.perl'>. Avoid using these in your code.
=head1 AUTHORS
Ingy döt Net <ingy@cpan.org>
Sisyphus <sisyphus@cpan.org>
=head1 COPYRIGHT AND LICENSE
Copyright 2000-2015. Ingy döt Net.
Copyright 2008, 2010-2014. Sisyphus.
This program is free software; you can redistribute it and/or modify it under
the same terms as Perl itself.
See L<http://www.perl.com/perl/misc/Artistic.html>
=cut
|