This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Lose the loose. Fix documentation typo.
[perl5.git] / dist / ExtUtils-ParseXS / lib / perlxstut.pod
1 =head1 NAME
2
3 perlxstut - Tutorial for writing XSUBs
4
5 =head1 DESCRIPTION
6
7 This tutorial will educate the reader on the steps involved in creating
8 a Perl extension.  The reader is assumed to have access to L<perlguts>,
9 L<perlapi> and L<perlxs>.
10
11 This tutorial starts with very simple examples and becomes more complex,
12 with each new example adding new features.  Certain concepts may not be
13 completely explained until later in the tutorial in order to slowly ease
14 the reader into building extensions.
15
16 This tutorial was written from a Unix point of view.  Where I know them
17 to be otherwise different for other platforms (e.g. Win32), I will list
18 them.  If you find something that was missed, please let me know.
19
20 =head1 SPECIAL NOTES
21
22 =head2 make
23
24 This tutorial assumes that the make program that Perl is configured to
25 use is called C<make>.  Instead of running "make" in the examples that
26 follow, you may have to substitute whatever make program Perl has been
27 configured to use.  Running B<perl -V:make> should tell you what it is.
28
29 =head2 Version caveat
30
31 When writing a Perl extension for general consumption, one should expect that
32 the extension will be used with versions of Perl different from the
33 version available on your machine.  Since you are reading this document,
34 the version of Perl on your machine is probably 5.005 or later, but the users
35 of your extension may have more ancient versions.
36
37 To understand what kinds of incompatibilities one may expect, and in the rare
38 case that the version of Perl on your machine is older than this document,
39 see the section on "Troubleshooting these Examples" for more information.
40
41 If your extension uses some features of Perl which are not available on older
42 releases of Perl, your users would appreciate an early meaningful warning.
43 You would probably put this information into the F<README> file, but nowadays
44 installation of extensions may be performed automatically, guided by F<CPAN.pm>
45 module or other tools.
46
47 In MakeMaker-based installations, F<Makefile.PL> provides the earliest
48 opportunity to perform version checks.  One can put something like this
49 in F<Makefile.PL> for this purpose:
50
51     eval { require 5.007 }
52         or die <<EOD;
53     ############
54     ### This module uses frobnication framework which is not available before
55     ### version 5.007 of Perl.  Upgrade your Perl before installing Kara::Mba.
56     ############
57     EOD
58
59 =head2 Dynamic Loading versus Static Loading
60
61 It is commonly thought that if a system does not have the capability to
62 dynamically load a library, you cannot build XSUBs.  This is incorrect.
63 You I<can> build them, but you must link the XSUBs subroutines with the
64 rest of Perl, creating a new executable.  This situation is similar to
65 Perl 4.
66
67 This tutorial can still be used on such a system.  The XSUB build mechanism
68 will check the system and build a dynamically-loadable library if possible,
69 or else a static library and then, optionally, a new statically-linked
70 executable with that static library linked in.
71
72 Should you wish to build a statically-linked executable on a system which
73 can dynamically load libraries, you may, in all the following examples,
74 where the command "C<make>" with no arguments is executed, run the command
75 "C<make perl>" instead.
76
77 If you have generated such a statically-linked executable by choice, then
78 instead of saying "C<make test>", you should say "C<make test_static>".
79 On systems that cannot build dynamically-loadable libraries at all, simply
80 saying "C<make test>" is sufficient.
81
82 =head1 TUTORIAL
83
84 Now let's go on with the show!
85
86 =head2 EXAMPLE 1
87
88 Our first extension will be very simple.  When we call the routine in the
89 extension, it will print out a well-known message and return.
90
91 Run "C<h2xs -A -n Mytest>".  This creates a directory named Mytest,
92 possibly under ext/ if that directory exists in the current working
93 directory.  Several files will be created under the Mytest dir, including
94 MANIFEST, Makefile.PL, lib/Mytest.pm, Mytest.xs, t/Mytest.t, and Changes.
95
96 The MANIFEST file contains the names of all the files just created in the
97 Mytest directory.
98
99 The file Makefile.PL should look something like this:
100
101     use ExtUtils::MakeMaker;
102     # See lib/ExtUtils/MakeMaker.pm for details of how to influence
103     # the contents of the Makefile that is written.
104     WriteMakefile(
105         NAME         => 'Mytest',
106         VERSION_FROM => 'Mytest.pm', # finds $VERSION
107         LIBS         => [''],   # e.g., '-lm'
108         DEFINE       => '',     # e.g., '-DHAVE_SOMETHING'
109         INC          => '',     # e.g., '-I/usr/include/other'
110     );
111
112 The file Mytest.pm should start with something like this:
113
114     package Mytest;
115
116     use 5.008008;
117     use strict;
118     use warnings;
119
120     require Exporter;
121
122     our @ISA = qw(Exporter);
123     our %EXPORT_TAGS = ( 'all' => [ qw(
124
125     ) ] );
126
127     our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'} } );
128
129     our @EXPORT = qw(
130
131     );
132
133     our $VERSION = '0.01';
134
135     require XSLoader;
136     XSLoader::load('Mytest', $VERSION);
137
138     # Preloaded methods go here.
139
140     1;
141     __END__
142     # Below is the stub of documentation for your module. You better edit it!
143
144 The rest of the .pm file contains sample code for providing documentation for
145 the extension.
146
147 Finally, the Mytest.xs file should look something like this:
148
149     #include "EXTERN.h"
150     #include "perl.h"
151     #include "XSUB.h"
152
153     #include "ppport.h"
154
155     MODULE = Mytest             PACKAGE = Mytest
156
157 Let's edit the .xs file by adding this to the end of the file:
158
159     void
160     hello()
161         CODE:
162             printf("Hello, world!\n");
163
164 It is okay for the lines starting at the "CODE:" line to not be indented.
165 However, for readability purposes, it is suggested that you indent CODE:
166 one level and the lines following one more level.
167
168 Now we'll run "C<perl Makefile.PL>".  This will create a real Makefile,
169 which make needs.  Its output looks something like:
170
171     % perl Makefile.PL
172     Checking if your kit is complete...
173     Looks good
174     Writing Makefile for Mytest
175     %
176
177 Now, running make will produce output that looks something like this (some
178 long lines have been shortened for clarity and some extraneous lines have
179 been deleted):
180
181     % make
182     cp lib/Mytest.pm blib/lib/Mytest.pm
183     perl xsubpp  -typemap typemap  Mytest.xs > Mytest.xsc && mv Mytest.xsc Mytest.c
184     Please specify prototyping behavior for Mytest.xs (see perlxs manual)
185     cc -c     Mytest.c
186     Running Mkbootstrap for Mytest ()
187     chmod 644 Mytest.bs
188     rm -f blib/arch/auto/Mytest/Mytest.so
189     cc  -shared -L/usr/local/lib Mytest.o  -o blib/arch/auto/Mytest/Mytest.so   \
190                 \
191
192     chmod 755 blib/arch/auto/Mytest/Mytest.so
193     cp Mytest.bs blib/arch/auto/Mytest/Mytest.bs
194     chmod 644 blib/arch/auto/Mytest/Mytest.bs
195     Manifying blib/man3/Mytest.3pm
196     %
197
198 You can safely ignore the line about "prototyping behavior" - it is
199 explained in L<perlxs/"The PROTOTYPES: Keyword">.
200
201 Perl has its own special way of easily writing test scripts, but for this
202 example only, we'll create our own test script.  Create a file called hello
203 that looks like this:
204
205     #! /opt/perl5/bin/perl
206
207     use ExtUtils::testlib;
208
209     use Mytest;
210
211     Mytest::hello();
212
213 Now we make the script executable (C<chmod +x hello>), run the script
214 and we should see the following output:
215
216     % ./hello
217     Hello, world!
218     %
219
220 =head2 EXAMPLE 2
221
222 Now let's add to our extension a subroutine that will take a single numeric
223 argument as input and return 1 if the number is even or 0 if the number
224 is odd.
225
226 Add the following to the end of Mytest.xs:
227
228     int
229     is_even(input)
230             int input
231         CODE:
232             RETVAL = (input % 2 == 0);
233         OUTPUT:
234             RETVAL
235
236 There does not need to be whitespace at the start of the "C<int input>"
237 line, but it is useful for improving readability.  Placing a semi-colon at
238 the end of that line is also optional.  Any amount and kind of whitespace
239 may be placed between the "C<int>" and "C<input>".
240
241 Now re-run make to rebuild our new shared library.
242
243 Now perform the same steps as before, generating a Makefile from the
244 Makefile.PL file, and running make.
245
246 In order to test that our extension works, we now need to look at the
247 file Mytest.t.  This file is set up to imitate the same kind of testing
248 structure that Perl itself has.  Within the test script, you perform a
249 number of tests to confirm the behavior of the extension, printing "ok"
250 when the test is correct, "not ok" when it is not.
251
252     use Test::More tests => 4;
253     BEGIN { use_ok('Mytest') };
254
255     #########################
256
257     # Insert your test code below, the Test::More module is use()ed here so read
258     # its man page ( perldoc Test::More ) for help writing this test script.
259
260     is(&Mytest::is_even(0), 1);
261     is(&Mytest::is_even(1), 0);
262     is(&Mytest::is_even(2), 1);
263
264 We will be calling the test script through the command "C<make test>".  You
265 should see output that looks something like this:
266
267     %make test
268     PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
269     t/Mytest....ok
270     All tests successful.
271     Files=1, Tests=4,  0 wallclock secs ( 0.03 cusr +  0.00 csys =  0.03 CPU)
272     %
273
274 =head2 What has gone on?
275
276 The program h2xs is the starting point for creating extensions.  In later
277 examples we'll see how we can use h2xs to read header files and generate
278 templates to connect to C routines.
279
280 h2xs creates a number of files in the extension directory.  The file
281 Makefile.PL is a perl script which will generate a true Makefile to build
282 the extension.  We'll take a closer look at it later.
283
284 The .pm and .xs files contain the meat of the extension.  The .xs file holds
285 the C routines that make up the extension.  The .pm file contains routines
286 that tell Perl how to load your extension.
287
288 Generating the Makefile and running C<make> created a directory called blib
289 (which stands for "build library") in the current working directory.  This
290 directory will contain the shared library that we will build.  Once we have
291 tested it, we can install it into its final location.
292
293 Invoking the test script via "C<make test>" did something very important.
294 It invoked perl with all those C<-I> arguments so that it could find the
295 various files that are part of the extension.  It is I<very> important that
296 while you are still testing extensions that you use "C<make test>".  If you
297 try to run the test script all by itself, you will get a fatal error.
298 Another reason it is important to use "C<make test>" to run your test
299 script is that if you are testing an upgrade to an already-existing version,
300 using "C<make test>" ensures that you will test your new extension, not the
301 already-existing version.
302
303 When Perl sees a C<use extension;>, it searches for a file with the same name
304 as the C<use>'d extension that has a .pm suffix.  If that file cannot be found,
305 Perl dies with a fatal error.  The default search path is contained in the
306 C<@INC> array.
307
308 In our case, Mytest.pm tells perl that it will need the Exporter and Dynamic
309 Loader extensions.  It then sets the C<@ISA> and C<@EXPORT> arrays and the
310 C<$VERSION> scalar; finally it tells perl to bootstrap the module.  Perl
311 will call its dynamic loader routine (if there is one) and load the shared
312 library.
313
314 The two arrays C<@ISA> and C<@EXPORT> are very important.  The C<@ISA>
315 array contains a list of other packages in which to search for methods (or
316 subroutines) that do not exist in the current package.  This is usually
317 only important for object-oriented extensions (which we will talk about
318 much later), and so usually doesn't need to be modified.
319
320 The C<@EXPORT> array tells Perl which of the extension's variables and
321 subroutines should be placed into the calling package's namespace.  Because
322 you don't know if the user has already used your variable and subroutine
323 names, it's vitally important to carefully select what to export.  Do I<not>
324 export method or variable names I<by default> without a good reason.
325
326 As a general rule, if the module is trying to be object-oriented then don't
327 export anything.  If it's just a collection of functions and variables, then
328 you can export them via another array, called C<@EXPORT_OK>.  This array
329 does not automatically place its subroutine and variable names into the
330 namespace unless the user specifically requests that this be done.
331
332 See L<perlmod> for more information.
333
334 The C<$VERSION> variable is used to ensure that the .pm file and the shared
335 library are "in sync" with each other.  Any time you make changes to
336 the .pm or .xs files, you should increment the value of this variable.
337
338 =head2 Writing good test scripts
339
340 The importance of writing good test scripts cannot be over-emphasized.  You
341 should closely follow the "ok/not ok" style that Perl itself uses, so that
342 it is very easy and unambiguous to determine the outcome of each test case.
343 When you find and fix a bug, make sure you add a test case for it.
344
345 By running "C<make test>", you ensure that your Mytest.t script runs and uses
346 the correct version of your extension.  If you have many test cases,
347 save your test files in the "t" directory and use the suffix ".t".
348 When you run "C<make test>", all of these test files will be executed.
349
350 =head2 EXAMPLE 3
351
352 Our third extension will take one argument as its input, round off that
353 value, and set the I<argument> to the rounded value.
354
355 Add the following to the end of Mytest.xs:
356
357         void
358         round(arg)
359                 double  arg
360             CODE:
361                 if (arg > 0.0) {
362                         arg = floor(arg + 0.5);
363                 } else if (arg < 0.0) {
364                         arg = ceil(arg - 0.5);
365                 } else {
366                         arg = 0.0;
367                 }
368             OUTPUT:
369                 arg
370
371 Edit the Makefile.PL file so that the corresponding line looks like this:
372
373         'LIBS'      => ['-lm'],   # e.g., '-lm'
374
375 Generate the Makefile and run make.  Change the test number in Mytest.t to
376 "9" and add the following tests:
377
378         $i = -1.5; &Mytest::round($i); is( $i, -2.0 );
379         $i = -1.1; &Mytest::round($i); is( $i, -1.0 );
380         $i = 0.0; &Mytest::round($i);  is( $i,  0.0 );
381         $i = 0.5; &Mytest::round($i);  is( $i,  1.0 );
382         $i = 1.2; &Mytest::round($i);  is( $i,  1.0 );
383
384 Running "C<make test>" should now print out that all nine tests are okay.
385
386 Notice that in these new test cases, the argument passed to round was a
387 scalar variable.  You might be wondering if you can round a constant or
388 literal.  To see what happens, temporarily add the following line to Mytest.t:
389
390         &Mytest::round(3);
391
392 Run "C<make test>" and notice that Perl dies with a fatal error.  Perl won't
393 let you change the value of constants!
394
395 =head2 What's new here?
396
397 =over 4
398
399 =item *
400
401 We've made some changes to Makefile.PL.  In this case, we've specified an
402 extra library to be linked into the extension's shared library, the math
403 library libm in this case.  We'll talk later about how to write XSUBs that
404 can call every routine in a library.
405
406 =item *
407
408 The value of the function is not being passed back as the function's return
409 value, but by changing the value of the variable that was passed into the
410 function.  You might have guessed that when you saw that the return value
411 of round is of type "void".
412
413 =back
414
415 =head2 Input and Output Parameters
416
417 You specify the parameters that will be passed into the XSUB on the line(s)
418 after you declare the function's return value and name.  Each input parameter
419 line starts with optional whitespace, and may have an optional terminating
420 semicolon.
421
422 The list of output parameters occurs at the very end of the function, just
423 after the OUTPUT: directive.  The use of RETVAL tells Perl that you
424 wish to send this value back as the return value of the XSUB function.  In
425 Example 3, we wanted the "return value" placed in the original variable
426 which we passed in, so we listed it (and not RETVAL) in the OUTPUT: section.
427
428 =head2 The XSUBPP Program
429
430 The B<xsubpp> program takes the XS code in the .xs file and translates it into
431 C code, placing it in a file whose suffix is .c.  The C code created makes
432 heavy use of the C functions within Perl.
433
434 =head2 The TYPEMAP file
435
436 The B<xsubpp> program uses rules to convert from Perl's data types (scalar,
437 array, etc.) to C's data types (int, char, etc.).  These rules are stored
438 in the typemap file ($PERLLIB/ExtUtils/typemap).  There's a brief discussion
439 below, but all the nitty-gritty details can be found in L<perlxstypemap>.
440 If you have a new-enough version of perl (5.16 and up) or an upgraded
441 XS compiler (C<ExtUtils::ParseXS> 3.13_01 or better), then you can inline
442 typemaps in your XS instead of writing separate files.
443 Either way, this typemap thing is split into three parts:
444
445 The first section maps various C data types to a name, which corresponds
446 somewhat with the various Perl types.  The second section contains C code
447 which B<xsubpp> uses to handle input parameters.  The third section contains
448 C code which B<xsubpp> uses to handle output parameters.
449
450 Let's take a look at a portion of the .c file created for our extension.
451 The file name is Mytest.c:
452
453         XS(XS_Mytest_round)
454         {
455             dXSARGS;
456             if (items != 1)
457                 Perl_croak(aTHX_ "Usage: Mytest::round(arg)");
458             PERL_UNUSED_VAR(cv); /* -W */
459             {
460                 double  arg = (double)SvNV(ST(0));      /* XXXXX */
461                 if (arg > 0.0) {
462                         arg = floor(arg + 0.5);
463                 } else if (arg < 0.0) {
464                         arg = ceil(arg - 0.5);
465                 } else {
466                         arg = 0.0;
467                 }
468                 sv_setnv(ST(0), (double)arg);   /* XXXXX */
469                 SvSETMAGIC(ST(0));
470             }
471             XSRETURN_EMPTY;
472         }
473
474 Notice the two lines commented with "XXXXX".  If you check the first part
475 of the typemap file (or section), you'll see that doubles are of type
476 T_DOUBLE.  In the INPUT part of the typemap, an argument that is T_DOUBLE
477 is assigned to the variable arg by calling the routine SvNV on something,
478 then casting it to double, then assigned to the variable arg.  Similarly,
479 in the OUTPUT section, once arg has its final value, it is passed to the
480 sv_setnv function to be passed back to the calling subroutine.  These two
481 functions are explained in L<perlguts>; we'll talk more later about what
482 that "ST(0)" means in the section on the argument stack.
483
484 =head2 Warning about Output Arguments
485
486 In general, it's not a good idea to write extensions that modify their input
487 parameters, as in Example 3.  Instead, you should probably return multiple
488 values in an array and let the caller handle them (we'll do this in a later
489 example).  However, in order to better accommodate calling pre-existing C
490 routines, which often do modify their input parameters, this behavior is
491 tolerated.
492
493 =head2 EXAMPLE 4
494
495 In this example, we'll now begin to write XSUBs that will interact with
496 pre-defined C libraries.  To begin with, we will build a small library of
497 our own, then let h2xs write our .pm and .xs files for us.
498
499 Create a new directory called Mytest2 at the same level as the directory
500 Mytest.  In the Mytest2 directory, create another directory called mylib,
501 and cd into that directory.
502
503 Here we'll create some files that will generate a test library.  These will
504 include a C source file and a header file.  We'll also create a Makefile.PL
505 in this directory.  Then we'll make sure that running make at the Mytest2
506 level will automatically run this Makefile.PL file and the resulting Makefile.
507
508 In the mylib directory, create a file mylib.h that looks like this:
509
510         #define TESTVAL 4
511
512         extern double   foo(int, long, const char*);
513
514 Also create a file mylib.c that looks like this:
515
516         #include <stdlib.h>
517         #include "./mylib.h"
518
519         double
520         foo(int a, long b, const char *c)
521         {
522                 return (a + b + atof(c) + TESTVAL);
523         }
524
525 And finally create a file Makefile.PL that looks like this:
526
527         use ExtUtils::MakeMaker;
528         $Verbose = 1;
529         WriteMakefile(
530             NAME   => 'Mytest2::mylib',
531             SKIP   => [qw(all static static_lib dynamic dynamic_lib)],
532             clean  => {'FILES' => 'libmylib$(LIB_EXT)'},
533         );
534
535
536         sub MY::top_targets {
537                 '
538         all :: static
539
540         pure_all :: static
541
542         static ::       libmylib$(LIB_EXT)
543
544         libmylib$(LIB_EXT): $(O_FILES)
545                 $(AR) cr libmylib$(LIB_EXT) $(O_FILES)
546                 $(RANLIB) libmylib$(LIB_EXT)
547
548         ';
549         }
550
551 Make sure you use a tab and not spaces on the lines beginning with "$(AR)"
552 and "$(RANLIB)".  Make will not function properly if you use spaces.
553 It has also been reported that the "cr" argument to $(AR) is unnecessary
554 on Win32 systems.
555
556 We will now create the main top-level Mytest2 files.  Change to the directory
557 above Mytest2 and run the following command:
558
559         % h2xs -O -n Mytest2 ./Mytest2/mylib/mylib.h
560
561 This will print out a warning about overwriting Mytest2, but that's okay.
562 Our files are stored in Mytest2/mylib, and will be untouched.
563
564 The normal Makefile.PL that h2xs generates doesn't know about the mylib
565 directory.  We need to tell it that there is a subdirectory and that we
566 will be generating a library in it.  Let's add the argument MYEXTLIB to
567 the WriteMakefile call so that it looks like this:
568
569         WriteMakefile(
570             'NAME'      => 'Mytest2',
571             'VERSION_FROM' => 'Mytest2.pm', # finds $VERSION
572             'LIBS'      => [''],   # e.g., '-lm'
573             'DEFINE'    => '',     # e.g., '-DHAVE_SOMETHING'
574             'INC'       => '',     # e.g., '-I/usr/include/other'
575             'MYEXTLIB' => 'mylib/libmylib$(LIB_EXT)',
576         );
577
578 and then at the end add a subroutine (which will override the pre-existing
579 subroutine).  Remember to use a tab character to indent the line beginning
580 with "cd"!
581
582         sub MY::postamble {
583         '
584         $(MYEXTLIB): mylib/Makefile
585                 cd mylib && $(MAKE) $(PASSTHRU)
586         ';
587         }
588
589 Let's also fix the MANIFEST file so that it accurately reflects the contents
590 of our extension.  The single line that says "mylib" should be replaced by
591 the following three lines:
592
593         mylib/Makefile.PL
594         mylib/mylib.c
595         mylib/mylib.h
596
597 To keep our namespace nice and unpolluted, edit the .pm file and change
598 the variable C<@EXPORT> to C<@EXPORT_OK>.  Finally, in the
599 .xs file, edit the #include line to read:
600
601         #include "mylib/mylib.h"
602
603 And also add the following function definition to the end of the .xs file:
604
605         double
606         foo(a,b,c)
607                 int             a
608                 long            b
609                 const char *    c
610             OUTPUT:
611                 RETVAL
612
613 Now we also need to create a typemap because the default Perl doesn't
614 currently support the C<const char *> type.  Include a new TYPEMAP
615 section in your XS code before the above function:
616
617         TYPEMAP: <<END;
618         const char *    T_PV
619         END
620
621 Now run perl on the top-level Makefile.PL.  Notice that it also created a
622 Makefile in the mylib directory.  Run make and watch that it does cd into
623 the mylib directory and run make in there as well.
624
625 Now edit the Mytest2.t script and change the number of tests to "4",
626 and add the following lines to the end of the script:
627
628         is( &Mytest2::foo(1, 2, "Hello, world!"), 7 );
629         is( &Mytest2::foo(1, 2, "0.0"), 7 );
630         ok( abs(&Mytest2::foo(0, 0, "-3.4") - 0.6) <= 0.01 );
631
632 (When dealing with floating-point comparisons, it is best to not check for
633 equality, but rather that the difference between the expected and actual
634 result is below a certain amount (called epsilon) which is 0.01 in this case)
635
636 Run "C<make test>" and all should be well. There are some warnings on missing tests
637 for the Mytest2::mylib extension, but you can ignore them.
638
639 =head2 What has happened here?
640
641 Unlike previous examples, we've now run h2xs on a real include file.  This
642 has caused some extra goodies to appear in both the .pm and .xs files.
643
644 =over 4
645
646 =item *
647
648 In the .xs file, there's now a #include directive with the absolute path to
649 the mylib.h header file.  We changed this to a relative path so that we
650 could move the extension directory if we wanted to.
651
652 =item *
653
654 There's now some new C code that's been added to the .xs file.  The purpose
655 of the C<constant> routine is to make the values that are #define'd in the
656 header file accessible by the Perl script (by calling either C<TESTVAL> or
657 C<&Mytest2::TESTVAL>).  There's also some XS code to allow calls to the
658 C<constant> routine.
659
660 =item *
661
662 The .pm file originally exported the name C<TESTVAL> in the C<@EXPORT> array.
663 This could lead to name clashes.  A good rule of thumb is that if the #define
664 is only going to be used by the C routines themselves, and not by the user,
665 they should be removed from the C<@EXPORT> array.  Alternately, if you don't
666 mind using the "fully qualified name" of a variable, you could move most
667 or all of the items from the C<@EXPORT> array into the C<@EXPORT_OK> array.
668
669 =item *
670
671 If our include file had contained #include directives, these would not have
672 been processed by h2xs.  There is no good solution to this right now.
673
674 =item *
675
676 We've also told Perl about the library that we built in the mylib
677 subdirectory.  That required only the addition of the C<MYEXTLIB> variable
678 to the WriteMakefile call and the replacement of the postamble subroutine
679 to cd into the subdirectory and run make.  The Makefile.PL for the
680 library is a bit more complicated, but not excessively so.  Again we
681 replaced the postamble subroutine to insert our own code.  This code
682 simply specified that the library to be created here was a static archive
683 library (as opposed to a dynamically loadable library) and provided the
684 commands to build it.
685
686 =back
687
688 =head2 Anatomy of .xs file
689
690 The .xs file of L<"EXAMPLE 4"> contained some new elements.  To understand
691 the meaning of these elements, pay attention to the line which reads
692
693         MODULE = Mytest2                PACKAGE = Mytest2
694
695 Anything before this line is plain C code which describes which headers
696 to include, and defines some convenience functions.  No translations are
697 performed on this part, apart from having embedded POD documentation
698 skipped over (see L<perlpod>) it goes into the generated output C file as is.
699
700 Anything after this line is the description of XSUB functions.
701 These descriptions are translated by B<xsubpp> into C code which
702 implements these functions using Perl calling conventions, and which
703 makes these functions visible from Perl interpreter.
704
705 Pay a special attention to the function C<constant>.  This name appears
706 twice in the generated .xs file: once in the first part, as a static C
707 function, then another time in the second part, when an XSUB interface to
708 this static C function is defined.
709
710 This is quite typical for .xs files: usually the .xs file provides
711 an interface to an existing C function.  Then this C function is defined
712 somewhere (either in an external library, or in the first part of .xs file),
713 and a Perl interface to this function (i.e. "Perl glue") is described in the
714 second part of .xs file.  The situation in L<"EXAMPLE 1">, L<"EXAMPLE 2">,
715 and L<"EXAMPLE 3">, when all the work is done inside the "Perl glue", is
716 somewhat of an exception rather than the rule.
717
718 =head2 Getting the fat out of XSUBs
719
720 In L<"EXAMPLE 4"> the second part of .xs file contained the following
721 description of an XSUB:
722
723         double
724         foo(a,b,c)
725                 int             a
726                 long            b
727                 const char *    c
728             OUTPUT:
729                 RETVAL
730
731 Note that in contrast with L<"EXAMPLE 1">, L<"EXAMPLE 2"> and L<"EXAMPLE 3">,
732 this description does not contain the actual I<code> for what is done
733 during a call to Perl function foo().  To understand what is going
734 on here, one can add a CODE section to this XSUB:
735
736         double
737         foo(a,b,c)
738                 int             a
739                 long            b
740                 const char *    c
741             CODE:
742                 RETVAL = foo(a,b,c);
743             OUTPUT:
744                 RETVAL
745
746 However, these two XSUBs provide almost identical generated C code: B<xsubpp>
747 compiler is smart enough to figure out the C<CODE:> section from the first
748 two lines of the description of XSUB.  What about C<OUTPUT:> section?  In
749 fact, that is absolutely the same!  The C<OUTPUT:> section can be removed
750 as well, I<as far as C<CODE:> section or C<PPCODE:> section> is not
751 specified: B<xsubpp> can see that it needs to generate a function call
752 section, and will autogenerate the OUTPUT section too.  Thus one can
753 shortcut the XSUB to become:
754
755         double
756         foo(a,b,c)
757                 int             a
758                 long            b
759                 const char *    c
760
761 Can we do the same with an XSUB
762
763         int
764         is_even(input)
765                 int     input
766             CODE:
767                 RETVAL = (input % 2 == 0);
768             OUTPUT:
769                 RETVAL
770
771 of L<"EXAMPLE 2">?  To do this, one needs to define a C function C<int
772 is_even(int input)>.  As we saw in L<Anatomy of .xs file>, a proper place
773 for this definition is in the first part of .xs file.  In fact a C function
774
775         int
776         is_even(int arg)
777         {
778                 return (arg % 2 == 0);
779         }
780
781 is probably overkill for this.  Something as simple as a C<#define> will
782 do too:
783
784         #define is_even(arg)    ((arg) % 2 == 0)
785
786 After having this in the first part of .xs file, the "Perl glue" part becomes
787 as simple as
788
789         int
790         is_even(input)
791                 int     input
792
793 This technique of separation of the glue part from the workhorse part has
794 obvious tradeoffs: if you want to change a Perl interface, you need to
795 change two places in your code.  However, it removes a lot of clutter,
796 and makes the workhorse part independent from idiosyncrasies of Perl calling
797 convention.  (In fact, there is nothing Perl-specific in the above description,
798 a different version of B<xsubpp> might have translated this to TCL glue or
799 Python glue as well.)
800
801 =head2 More about XSUB arguments
802
803 With the completion of Example 4, we now have an easy way to simulate some
804 real-life libraries whose interfaces may not be the cleanest in the world.
805 We shall now continue with a discussion of the arguments passed to the
806 B<xsubpp> compiler.
807
808 When you specify arguments to routines in the .xs file, you are really
809 passing three pieces of information for each argument listed.  The first
810 piece is the order of that argument relative to the others (first, second,
811 etc).  The second is the type of argument, and consists of the type
812 declaration of the argument (e.g., int, char*, etc).  The third piece is
813 the calling convention for the argument in the call to the library function.
814
815 While Perl passes arguments to functions by reference,
816 C passes arguments by value; to implement a C function which modifies data
817 of one of the "arguments", the actual argument of this C function would be
818 a pointer to the data.  Thus two C functions with declarations
819
820         int string_length(char *s);
821         int upper_case_char(char *cp);
822
823 may have completely different semantics: the first one may inspect an array
824 of chars pointed by s, and the second one may immediately dereference C<cp>
825 and manipulate C<*cp> only (using the return value as, say, a success
826 indicator).  From Perl one would use these functions in
827 a completely different manner.
828
829 One conveys this info to B<xsubpp> by replacing C<*> before the
830 argument by C<&>.  C<&> means that the argument should be passed to a library
831 function by its address.  The above two function may be XSUB-ified as
832
833         int
834         string_length(s)
835                 char *  s
836
837         int
838         upper_case_char(cp)
839                 char    &cp
840
841 For example, consider:
842
843         int
844         foo(a,b)
845                 char    &a
846                 char *  b
847
848 The first Perl argument to this function would be treated as a char and assigned
849 to the variable a, and its address would be passed into the function foo.
850 The second Perl argument would be treated as a string pointer and assigned to the
851 variable b.  The I<value> of b would be passed into the function foo.  The
852 actual call to the function foo that B<xsubpp> generates would look like this:
853
854         foo(&a, b);
855
856 B<xsubpp> will parse the following function argument lists identically:
857
858         char    &a
859         char&a
860         char    & a
861
862 However, to help ease understanding, it is suggested that you place a "&"
863 next to the variable name and away from the variable type), and place a
864 "*" near the variable type, but away from the variable name (as in the
865 call to foo above).  By doing so, it is easy to understand exactly what
866 will be passed to the C function; it will be whatever is in the "last
867 column".
868
869 You should take great pains to try to pass the function the type of variable
870 it wants, when possible.  It will save you a lot of trouble in the long run.
871
872 =head2 The Argument Stack
873
874 If we look at any of the C code generated by any of the examples except
875 example 1, you will notice a number of references to ST(n), where n is
876 usually 0.  "ST" is actually a macro that points to the n'th argument
877 on the argument stack.  ST(0) is thus the first argument on the stack and
878 therefore the first argument passed to the XSUB, ST(1) is the second
879 argument, and so on.
880
881 When you list the arguments to the XSUB in the .xs file, that tells B<xsubpp>
882 which argument corresponds to which of the argument stack (i.e., the first
883 one listed is the first argument, and so on).  You invite disaster if you
884 do not list them in the same order as the function expects them.
885
886 The actual values on the argument stack are pointers to the values passed
887 in.  When an argument is listed as being an OUTPUT value, its corresponding
888 value on the stack (i.e., ST(0) if it was the first argument) is changed.
889 You can verify this by looking at the C code generated for Example 3.
890 The code for the round() XSUB routine contains lines that look like this:
891
892         double  arg = (double)SvNV(ST(0));
893         /* Round the contents of the variable arg */
894         sv_setnv(ST(0), (double)arg);
895
896 The arg variable is initially set by taking the value from ST(0), then is
897 stored back into ST(0) at the end of the routine.
898
899 XSUBs are also allowed to return lists, not just scalars.  This must be
900 done by manipulating stack values ST(0), ST(1), etc, in a subtly
901 different way.  See L<perlxs> for details.
902
903 XSUBs are also allowed to avoid automatic conversion of Perl function arguments
904 to C function arguments.  See L<perlxs> for details.  Some people prefer
905 manual conversion by inspecting C<ST(i)> even in the cases when automatic
906 conversion will do, arguing that this makes the logic of an XSUB call clearer.
907 Compare with L<"Getting the fat out of XSUBs"> for a similar tradeoff of
908 a complete separation of "Perl glue" and "workhorse" parts of an XSUB.
909
910 While experts may argue about these idioms, a novice to Perl guts may
911 prefer a way which is as little Perl-guts-specific as possible, meaning
912 automatic conversion and automatic call generation, as in
913 L<"Getting the fat out of XSUBs">.  This approach has the additional
914 benefit of protecting the XSUB writer from future changes to the Perl API.
915
916 =head2 Extending your Extension
917
918 Sometimes you might want to provide some extra methods or subroutines
919 to assist in making the interface between Perl and your extension simpler
920 or easier to understand.  These routines should live in the .pm file.
921 Whether they are automatically loaded when the extension itself is loaded
922 or only loaded when called depends on where in the .pm file the subroutine
923 definition is placed.  You can also consult L<AutoLoader> for an alternate
924 way to store and load your extra subroutines.
925
926 =head2 Documenting your Extension
927
928 There is absolutely no excuse for not documenting your extension.
929 Documentation belongs in the .pm file.  This file will be fed to pod2man,
930 and the embedded documentation will be converted to the manpage format,
931 then placed in the blib directory.  It will be copied to Perl's
932 manpage directory when the extension is installed.
933
934 You may intersperse documentation and Perl code within the .pm file.
935 In fact, if you want to use method autoloading, you must do this,
936 as the comment inside the .pm file explains.
937
938 See L<perlpod> for more information about the pod format.
939
940 =head2 Installing your Extension
941
942 Once your extension is complete and passes all its tests, installing it
943 is quite simple: you simply run "make install".  You will either need
944 to have write permission into the directories where Perl is installed,
945 or ask your system administrator to run the make for you.
946
947 Alternately, you can specify the exact directory to place the extension's
948 files by placing a "PREFIX=/destination/directory" after the make install.
949 (or in between the make and install if you have a brain-dead version of make).
950 This can be very useful if you are building an extension that will eventually
951 be distributed to multiple systems.  You can then just archive the files in
952 the destination directory and distribute them to your destination systems.
953
954 =head2 EXAMPLE 5
955
956 In this example, we'll do some more work with the argument stack.  The
957 previous examples have all returned only a single value.  We'll now
958 create an extension that returns an array.
959
960 This extension is very Unix-oriented (struct statfs and the statfs system
961 call).  If you are not running on a Unix system, you can substitute for
962 statfs any other function that returns multiple values, you can hard-code
963 values to be returned to the caller (although this will be a bit harder
964 to test the error case), or you can simply not do this example.  If you
965 change the XSUB, be sure to fix the test cases to match the changes.
966
967 Return to the Mytest directory and add the following code to the end of
968 Mytest.xs:
969
970         void
971         statfs(path)
972                 char *  path
973             INIT:
974                 int i;
975                 struct statfs buf;
976
977             PPCODE:
978                 i = statfs(path, &buf);
979                 if (i == 0) {
980                         XPUSHs(sv_2mortal(newSVnv(buf.f_bavail)));
981                         XPUSHs(sv_2mortal(newSVnv(buf.f_bfree)));
982                         XPUSHs(sv_2mortal(newSVnv(buf.f_blocks)));
983                         XPUSHs(sv_2mortal(newSVnv(buf.f_bsize)));
984                         XPUSHs(sv_2mortal(newSVnv(buf.f_ffree)));
985                         XPUSHs(sv_2mortal(newSVnv(buf.f_files)));
986                         XPUSHs(sv_2mortal(newSVnv(buf.f_type)));
987                 } else {
988                         XPUSHs(sv_2mortal(newSVnv(errno)));
989                 }
990
991 You'll also need to add the following code to the top of the .xs file, just
992 after the include of "XSUB.h":
993
994         #include <sys/vfs.h>
995
996 Also add the following code segment to Mytest.t while incrementing the "9"
997 tests to "11":
998
999         @a = &Mytest::statfs("/blech");
1000         ok( scalar(@a) == 1 && $a[0] == 2 );
1001         @a = &Mytest::statfs("/");
1002         is( scalar(@a), 7 );
1003
1004 =head2 New Things in this Example
1005
1006 This example added quite a few new concepts.  We'll take them one at a time.
1007
1008 =over 4
1009
1010 =item *
1011
1012 The INIT: directive contains code that will be placed immediately after
1013 the argument stack is decoded.  C does not allow variable declarations at
1014 arbitrary locations inside a function,
1015 so this is usually the best way to declare local variables needed by the XSUB.
1016 (Alternatively, one could put the whole C<PPCODE:> section into braces, and
1017 put these declarations on top.)
1018
1019 =item *
1020
1021 This routine also returns a different number of arguments depending on the
1022 success or failure of the call to statfs.  If there is an error, the error
1023 number is returned as a single-element array.  If the call is successful,
1024 then a 7-element array is returned.  Since only one argument is passed into
1025 this function, we need room on the stack to hold the 7 values which may be
1026 returned.
1027
1028 We do this by using the PPCODE: directive, rather than the CODE: directive.
1029 This tells B<xsubpp> that we will be managing the return values that will be
1030 put on the argument stack by ourselves.
1031
1032 =item *
1033
1034 When we want to place values to be returned to the caller onto the stack,
1035 we use the series of macros that begin with "XPUSH".  There are five
1036 different versions, for placing integers, unsigned integers, doubles,
1037 strings, and Perl scalars on the stack.  In our example, we placed a
1038 Perl scalar onto the stack.  (In fact this is the only macro which
1039 can be used to return multiple values.)
1040
1041 The XPUSH* macros will automatically extend the return stack to prevent
1042 it from being overrun.  You push values onto the stack in the order you
1043 want them seen by the calling program.
1044
1045 =item *
1046
1047 The values pushed onto the return stack of the XSUB are actually mortal SV's.
1048 They are made mortal so that once the values are copied by the calling
1049 program, the SV's that held the returned values can be deallocated.
1050 If they were not mortal, then they would continue to exist after the XSUB
1051 routine returned, but would not be accessible.  This is a memory leak.
1052
1053 =item *
1054
1055 If we were interested in performance, not in code compactness, in the success
1056 branch we would not use C<XPUSHs> macros, but C<PUSHs> macros, and would
1057 pre-extend the stack before pushing the return values:
1058
1059         EXTEND(SP, 7);
1060
1061 The tradeoff is that one needs to calculate the number of return values
1062 in advance (though overextending the stack will not typically hurt
1063 anything but memory consumption).
1064
1065 Similarly, in the failure branch we could use C<PUSHs> I<without> extending
1066 the stack: the Perl function reference comes to an XSUB on the stack, thus
1067 the stack is I<always> large enough to take one return value.
1068
1069 =back
1070
1071 =head2 EXAMPLE 6
1072
1073 In this example, we will accept a reference to an array as an input
1074 parameter, and return a reference to an array of hashes.  This will
1075 demonstrate manipulation of complex Perl data types from an XSUB.
1076
1077 This extension is somewhat contrived.  It is based on the code in
1078 the previous example.  It calls the statfs function multiple times,
1079 accepting a reference to an array of filenames as input, and returning
1080 a reference to an array of hashes containing the data for each of the
1081 filesystems.
1082
1083 Return to the Mytest directory and add the following code to the end of
1084 Mytest.xs:
1085
1086     SV *
1087     multi_statfs(paths)
1088             SV * paths
1089         INIT:
1090             AV * results;
1091             I32 numpaths = 0;
1092             int i, n;
1093             struct statfs buf;
1094
1095             SvGETMAGIC(paths);
1096             if ((!SvROK(paths))
1097                 || (SvTYPE(SvRV(paths)) != SVt_PVAV)
1098                 || ((numpaths = av_len((AV *)SvRV(paths))) < 0))
1099             {
1100                 XSRETURN_UNDEF;
1101             }
1102             results = (AV *)sv_2mortal((SV *)newAV());
1103         CODE:
1104             for (n = 0; n <= numpaths; n++) {
1105                 HV * rh;
1106                 STRLEN l;
1107                 char * fn = SvPV(*av_fetch((AV *)SvRV(paths), n, 0), l);
1108
1109                 i = statfs(fn, &buf);
1110                 if (i != 0) {
1111                     av_push(results, newSVnv(errno));
1112                     continue;
1113                 }
1114
1115                 rh = (HV *)sv_2mortal((SV *)newHV());
1116
1117                 hv_store(rh, "f_bavail", 8, newSVnv(buf.f_bavail), 0);
1118                 hv_store(rh, "f_bfree",  7, newSVnv(buf.f_bfree),  0);
1119                 hv_store(rh, "f_blocks", 8, newSVnv(buf.f_blocks), 0);
1120                 hv_store(rh, "f_bsize",  7, newSVnv(buf.f_bsize),  0);
1121                 hv_store(rh, "f_ffree",  7, newSVnv(buf.f_ffree),  0);
1122                 hv_store(rh, "f_files",  7, newSVnv(buf.f_files),  0);
1123                 hv_store(rh, "f_type",   6, newSVnv(buf.f_type),   0);
1124
1125                 av_push(results, newRV((SV *)rh));
1126             }
1127             RETVAL = newRV((SV *)results);
1128         OUTPUT:
1129             RETVAL
1130
1131 And add the following code to Mytest.t, while incrementing the "11"
1132 tests to "13":
1133
1134         $results = Mytest::multi_statfs([ '/', '/blech' ]);
1135         ok( ref $results->[0] );
1136         ok( ! ref $results->[1] );
1137
1138 =head2 New Things in this Example
1139
1140 There are a number of new concepts introduced here, described below:
1141
1142 =over 4
1143
1144 =item *
1145
1146 This function does not use a typemap.  Instead, we declare it as accepting
1147 one SV* (scalar) parameter, and returning an SV* value, and we take care of
1148 populating these scalars within the code.  Because we are only returning
1149 one value, we don't need a C<PPCODE:> directive - instead, we use C<CODE:>
1150 and C<OUTPUT:> directives.
1151
1152 =item *
1153
1154 When dealing with references, it is important to handle them with caution.
1155 The C<INIT:> block first calls SvGETMAGIC(paths), in case
1156 paths is a tied variable.  Then it checks that C<SvROK> returns
1157 true, which indicates that paths is a valid reference.  (Simply
1158 checking C<SvROK> won't trigger FETCH on a tied variable.)  It
1159 then verifies that the object referenced by paths is an array, using C<SvRV>
1160 to dereference paths, and C<SvTYPE> to discover its type.  As an added test,
1161 it checks that the array referenced by paths is non-empty, using the C<av_len>
1162 function (which returns -1 if the array is empty).  The XSRETURN_UNDEF macro
1163 is used to abort the XSUB and return the undefined value whenever all three of
1164 these conditions are not met.
1165
1166 =item *
1167
1168 We manipulate several arrays in this XSUB.  Note that an array is represented
1169 internally by an AV* pointer.  The functions and macros for manipulating
1170 arrays are similar to the functions in Perl: C<av_len> returns the highest
1171 index in an AV*, much like $#array; C<av_fetch> fetches a single scalar value
1172 from an array, given its index; C<av_push> pushes a scalar value onto the
1173 end of the array, automatically extending the array as necessary.
1174
1175 Specifically, we read pathnames one at a time from the input array, and
1176 store the results in an output array (results) in the same order.  If
1177 statfs fails, the element pushed onto the return array is the value of
1178 errno after the failure.  If statfs succeeds, though, the value pushed
1179 onto the return array is a reference to a hash containing some of the
1180 information in the statfs structure.
1181
1182 As with the return stack, it would be possible (and a small performance win)
1183 to pre-extend the return array before pushing data into it, since we know
1184 how many elements we will return:
1185
1186         av_extend(results, numpaths);
1187
1188 =item *
1189
1190 We are performing only one hash operation in this function, which is storing
1191 a new scalar under a key using C<hv_store>.  A hash is represented by an HV*
1192 pointer.  Like arrays, the functions for manipulating hashes from an XSUB
1193 mirror the functionality available from Perl.  See L<perlguts> and L<perlapi>
1194 for details.
1195
1196 =item *
1197
1198 To create a reference, we use the C<newRV> function.  Note that you can
1199 cast an AV* or an HV* to type SV* in this case (and many others).  This
1200 allows you to take references to arrays, hashes and scalars with the same
1201 function.  Conversely, the C<SvRV> function always returns an SV*, which may
1202 need to be cast to the appropriate type if it is something other than a
1203 scalar (check with C<SvTYPE>).
1204
1205 =item *
1206
1207 At this point, xsubpp is doing very little work - the differences between
1208 Mytest.xs and Mytest.c are minimal.
1209
1210 =back
1211
1212 =head2 EXAMPLE 7 (Coming Soon)
1213
1214 XPUSH args AND set RETVAL AND assign return value to array
1215
1216 =head2 EXAMPLE 8 (Coming Soon)
1217
1218 Setting $!
1219
1220 =head2 EXAMPLE 9 Passing open files to XSes
1221
1222 You would think passing files to an XS is difficult, with all the
1223 typeglobs and stuff. Well, it isn't.
1224
1225 Suppose that for some strange reason we need a wrapper around the
1226 standard C library function C<fputs()>. This is all we need:
1227
1228         #define PERLIO_NOT_STDIO 0
1229         #include "EXTERN.h"
1230         #include "perl.h"
1231         #include "XSUB.h"
1232
1233         #include <stdio.h>
1234
1235         int
1236         fputs(s, stream)
1237                 char *          s
1238                 FILE *          stream
1239
1240 The real work is done in the standard typemap.
1241
1242 B<But> you lose all the fine stuff done by the perlio layers. This
1243 calls the stdio function C<fputs()>, which knows nothing about them.
1244
1245 The standard typemap offers three variants of PerlIO *:
1246 C<InputStream> (T_IN), C<InOutStream> (T_INOUT) and C<OutputStream>
1247 (T_OUT). A bare C<PerlIO *> is considered a T_INOUT. If it matters
1248 in your code (see below for why it might) #define or typedef
1249 one of the specific names and use that as the argument or result
1250 type in your XS file.
1251
1252 The standard typemap does not contain PerlIO * before perl 5.7,
1253 but it has the three stream variants. Using a PerlIO * directly
1254 is not backwards compatible unless you provide your own typemap.
1255
1256 For streams coming I<from> perl the main difference is that
1257 C<OutputStream> will get the output PerlIO * - which may make
1258 a difference on a socket. Like in our example...
1259
1260 For streams being handed I<to> perl a new file handle is created
1261 (i.e. a reference to a new glob) and associated with the PerlIO *
1262 provided. If the read/write state of the PerlIO * is not correct then you
1263 may get errors or warnings from when the file handle is used.
1264 So if you opened the PerlIO * as "w" it should really be an
1265 C<OutputStream> if open as "r" it should be an C<InputStream>.
1266
1267 Now, suppose you want to use perlio layers in your XS. We'll use the
1268 perlio C<PerlIO_puts()> function as an example.
1269
1270 In the C part of the XS file (above the first MODULE line) you
1271 have
1272
1273         #define OutputStream    PerlIO *
1274     or
1275         typedef PerlIO *        OutputStream;
1276
1277
1278 And this is the XS code:
1279
1280         int
1281         perlioputs(s, stream)
1282                 char *          s
1283                 OutputStream    stream
1284         CODE:
1285                 RETVAL = PerlIO_puts(stream, s);
1286         OUTPUT:
1287                 RETVAL
1288
1289 We have to use a C<CODE> section because C<PerlIO_puts()> has the arguments
1290 reversed compared to C<fputs()>, and we want to keep the arguments the same.
1291
1292 Wanting to explore this thoroughly, we want to use the stdio C<fputs()>
1293 on a PerlIO *. This means we have to ask the perlio system for a stdio
1294 C<FILE *>:
1295
1296         int
1297         perliofputs(s, stream)
1298                 char *          s
1299                 OutputStream    stream
1300         PREINIT:
1301                 FILE *fp = PerlIO_findFILE(stream);
1302         CODE:
1303                 if (fp != (FILE*) 0) {
1304                         RETVAL = fputs(s, fp);
1305                 } else {
1306                         RETVAL = -1;
1307                 }
1308         OUTPUT:
1309                 RETVAL
1310
1311 Note: C<PerlIO_findFILE()> will search the layers for a stdio
1312 layer. If it can't find one, it will call C<PerlIO_exportFILE()> to
1313 generate a new stdio C<FILE>. Please only call C<PerlIO_exportFILE()> if
1314 you want a I<new> C<FILE>. It will generate one on each call and push a
1315 new stdio layer. So don't call it repeatedly on the same
1316 file. C<PerlIO_findFILE()> will retrieve the stdio layer once it has been
1317 generated by C<PerlIO_exportFILE()>.
1318
1319 This applies to the perlio system only. For versions before 5.7,
1320 C<PerlIO_exportFILE()> is equivalent to C<PerlIO_findFILE()>.
1321
1322 =head2 Troubleshooting these Examples
1323
1324 As mentioned at the top of this document, if you are having problems with
1325 these example extensions, you might see if any of these help you.
1326
1327 =over 4
1328
1329 =item *
1330
1331 In versions of 5.002 prior to the gamma version, the test script in Example
1332 1 will not function properly.  You need to change the "use lib" line to
1333 read:
1334
1335         use lib './blib';
1336
1337 =item *
1338
1339 In versions of 5.002 prior to version 5.002b1h, the test.pl file was not
1340 automatically created by h2xs.  This means that you cannot say "make test"
1341 to run the test script.  You will need to add the following line before the
1342 "use extension" statement:
1343
1344         use lib './blib';
1345
1346 =item *
1347
1348 In versions 5.000 and 5.001, instead of using the above line, you will need
1349 to use the following line:
1350
1351         BEGIN { unshift(@INC, "./blib") }
1352
1353 =item *
1354
1355 This document assumes that the executable named "perl" is Perl version 5.
1356 Some systems may have installed Perl version 5 as "perl5".
1357
1358 =back
1359
1360 =head1 See also
1361
1362 For more information, consult L<perlguts>, L<perlapi>, L<perlxs>, L<perlmod>,
1363 and L<perlpod>.
1364
1365 =head1 Author
1366
1367 Jeff Okamoto <F<okamoto@corp.hp.com>>
1368
1369 Reviewed and assisted by Dean Roehrich, Ilya Zakharevich, Andreas Koenig,
1370 and Tim Bunce.
1371
1372 PerlIO material contributed by Lupe Christoph, with some clarification
1373 by Nick Ing-Simmons.
1374
1375 Changes for h2xs as of Perl 5.8.x by Renee Baecker
1376
1377 =head2 Last Changed
1378
1379 2012-01-20