Skip to content

Commit 34f73e1

Browse files
committed
perlxs.pod: update: Input part, PREINIT sections
Add text for the new '=head2 The XSUB Input Part' section, and rewrite the existing entry for the PREINIT keyword.
1 parent d8dcfe7 commit 34f73e1

File tree

1 file changed

+62
-95
lines changed

1 file changed

+62
-95
lines changed

dist/ExtUtils-ParseXS/lib/perlxs.pod

Lines changed: 62 additions & 95 deletions
Original file line numberDiff line numberDiff line change
@@ -2520,111 +2520,78 @@ stack, then replaces the items on the stack one by one.
25202520

25212521
=head2 The XSUB Input Part
25222522

2523-
XXX TBC
2524-
2525-
XXX NB: the keywords described in L<XSUB Generic Keywords> and L<Sharing
2526-
XSUB bodies> may also appear in this part, plus C<C_ARGS> and
2527-
C<INTERFACE_MACRO>.
2523+
Following an XSUB's declaration part, the body of the XSUB follows. The
2524+
first part of the body is the I<input> part, and is mainly concerned with
2525+
declaring auto variables and assigning to them values extracted from the
2526+
passed parameters. The two main keywords associated with this activity are
2527+
L<PREINIT|/The PREINIT: Keyword> and L<INPUT|/The INPUT: Keyword>. The
2528+
first allows you to inject extra variable declaration lines, while the
2529+
latter used to be needed to specify the type of each parameter, but is now
2530+
mainly of historical interest. This is also the place for the rarely-used
2531+
L<SCOPE|/The SCOPE: Keyword> keyword.
2532+
2533+
Note that the keywords described in L<XSUB Generic Keywords> and L<Sharing
2534+
XSUB bodies> may also appear in this part, plus the L<C_ARGS|/The C_ARGS:
2535+
Keyword> and L<INTERFACE_MACRO|/The INTERFACE_MACRO: Keyword> keywords.
25282536

25292537
=head3 The PREINIT: Keyword
25302538

2531-
The PREINIT: keyword allows extra variables to be declared immediately
2532-
before or after the declarations of the parameters from the INPUT: section
2533-
are emitted.
2534-
2535-
If a variable is declared inside a CODE: section it will follow any typemap
2536-
code that is emitted for the input parameters. This may result in the
2537-
declaration ending up after C code, which is C syntax error. Similar
2538-
errors may happen with an explicit C<;>-type or C<+>-type initialization of
2539-
parameters is used (see L<"Initializing Function Parameters">). Declaring
2540-
these variables in an INIT: section will not help.
2541-
2542-
In such cases, to force an additional variable to be declared together
2543-
with declarations of other variables, place the declaration into a
2544-
PREINIT: section. The PREINIT: keyword may be used one or more times
2545-
within an XSUB.
2546-
2547-
The following examples are equivalent, but if the code is using complex
2548-
typemaps then the first example is safer.
2539+
PREINIT:
2540+
int i;
2541+
char *prog_name = get_prog_name();
2542+
2543+
This keyword allows extra variables to be declared and possibly
2544+
initialised immediately before the declarations of auto variables
2545+
generated from any parameter declarations or C<INPUT> lines. Any lines
2546+
following C<PREINIT> until the next keyword (except POD and XS comments)
2547+
are copied out as-is to the C code file. Multiple C<PREINIT> keywords are
2548+
allowed.
2549+
2550+
It is sometimes needed because in traditional C, all variable
2551+
declarations must come before any statements. While this is no longer a
2552+
restriction in the perl interpreter source since 5.36.0, the C compiler
2553+
flags used when compiling XS code may be different and so, depending on
2554+
the compiler, it may still be necessary to preserve the correct ordering.
2555+
2556+
Any variable declarations generated by C<INPUT> and lines from C<PREINIT>
2557+
are output in the same order they appear in the XS source, followed by any
2558+
variable declarations generated from the XSUB's parameter declarations.
2559+
These may be followed by statements to initialise those those variables.
2560+
Thus, any variable declarations in a later C<INIT> or C<CODE> block may be
2561+
flagged as a declaration-after-statement.
2562+
2563+
C<PREINIT> code shouldn't assume that any variables declared earlier have
2564+
already been initialised; initialisation is deferred if the initialisation
2565+
code (typically obtained from a typemap) isn't of the simple C<type var =
2566+
init;> form, or has a default value.
25492567

2550-
bool_t
2551-
rpcb_gettime(timep)
2552-
time_t timep = NO_INIT
2553-
PREINIT:
2554-
char *host = "localhost";
2555-
CODE:
2556-
RETVAL = rpcb_gettime(host, &timep);
2557-
OUTPUT:
2558-
timep
2559-
RETVAL
2568+
For example:
25602569

2561-
For this particular case an INIT: keyword would generate the
2562-
same C code as the PREINIT: keyword. Another correct, but error-prone example:
2570+
void
2571+
foo(int i = 0)
2572+
PREINIT:
2573+
int j = 1;
2574+
CODE:
2575+
bar(i, j);
25632576

2564-
bool_t
2565-
rpcb_gettime(timep)
2566-
time_t timep = NO_INIT
2567-
CODE:
2568-
char *host = "localhost";
2569-
RETVAL = rpcb_gettime(host, &timep);
2570-
OUTPUT:
2571-
timep
2572-
RETVAL
2577+
might be translated into C code similar to:
25732578

2574-
Another way to declare C<host> is to use a C block in the CODE: section:
2579+
{
2580+
int j = 1;
2581+
int i;
25752582

2576-
bool_t
2577-
rpcb_gettime(timep)
2578-
time_t timep = NO_INIT
2579-
CODE:
2580-
{
2581-
char *host = "localhost";
2582-
RETVAL = rpcb_gettime(host, &timep);
2583+
if (items < 1)
2584+
i = 0;
2585+
else {
2586+
i = (int)SvIV(ST(0));
25832587
}
2584-
OUTPUT:
2585-
timep
2586-
RETVAL
2587-
2588-
The ability to put additional declarations before the typemap entries are
2589-
processed is very handy in the cases when typemap conversions manipulate
2590-
some global state:
2591-
2592-
MyObject
2593-
mutate(o)
2594-
PREINIT:
2595-
MyState st = global_state;
2596-
INPUT:
2597-
MyObject o;
2598-
CLEANUP:
2599-
reset_to(global_state, st);
2600-
2601-
Here we suppose that conversion to C<MyObject> in the INPUT: section and from
2602-
MyObject when processing RETVAL will modify a global variable C<global_state>.
2603-
After these conversions are performed, we restore the old value of
2604-
C<global_state> (to avoid memory leaks, for example).
2605-
2606-
There is another way to trade clarity for compactness: INPUT sections allow
2607-
declaration of C variables which do not appear in the parameter list of
2608-
a subroutine. Thus the above code for mutate() can be rewritten as
2609-
2610-
MyObject
2611-
mutate(o)
2612-
MyState st = global_state;
2613-
MyObject o;
2614-
CLEANUP:
2615-
reset_to(global_state, st);
2616-
2617-
and the code for rpcb_gettime() can be rewritten as
2588+
bar(i, j);
2589+
}
26182590

2619-
bool_t
2620-
rpcb_gettime(timep)
2621-
time_t timep = NO_INIT
2622-
char *host = "localhost";
2623-
C_ARGS:
2624-
host, &timep
2625-
OUTPUT:
2626-
timep
2627-
RETVAL
2591+
Usually you could dispense with C<PREINIT> by just wrapping the code in
2592+
C<CODE> blocks in braces, but it may be necessary if the ordering of the
2593+
variable initialisations is sensitive, e.g. if it affected by some
2594+
changing global state.
26282595

26292596
=head3 The INPUT: Keyword
26302597

0 commit comments

Comments
 (0)