This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
typo fixes for ExtUtils::ParseXS
authorDavid Steinbrunner <dsteinbrunner@pobox.com>
Tue, 21 May 2013 11:08:49 +0000 (07:08 -0400)
committerJames E Keenan <jkeenan@cpan.org>
Sat, 25 May 2013 03:12:44 +0000 (05:12 +0200)
dist/ExtUtils-ParseXS/lib/perlxs.pod
dist/ExtUtils-ParseXS/lib/perlxstypemap.pod

index 11fc13c..4d67aaf 100644 (file)
@@ -556,7 +556,7 @@ not care about its initial contents.
 Starting with Perl 5.16, you can embed typemaps into your XS code
 instead of or in addition to typemaps in a separate file.  Multiple
 such embedded typemaps will be processed in order of appearance in
-the XS code and like local typemap files take precendence over the
+the XS code and like local typemap files take precedence over the
 default typemap, the embedded typemaps may overwrite previous
 definitions of TYPEMAP, INPUT, and OUTPUT stanzas.  The syntax for
 embedded typemaps is
@@ -1958,7 +1958,7 @@ of C<my_cxt_t>.
 
 =item MY_CXT_INIT
 
-The MY_CXT_INIT macro initialises storage for the C<my_cxt_t> struct.
+The MY_CXT_INIT macro initializes storage for the C<my_cxt_t> struct.
 
 It I<must> be called exactly once, typically in a BOOT: section. If you
 are maintaining multiple interpreters, it should be called once in each
index 94bd037..e2bc7ed 100644 (file)
@@ -159,7 +159,7 @@ has default XS types for a large number of C types.  For example, if
 you simply return a C<char *> from your XSUB, the core typemap will
 have this C type associated with the T_PV XS type.  That means your
 C string will be copied into the PV (pointer value) slot of a new scalar
-that will be returned from your XSUB to to Perl.
+that will be returned from your XSUB to Perl.
 
 If you're developing a CPAN distribution using XS, you may add your own
 file called F<typemap> to the distribution.  That file may contain
@@ -595,7 +595,7 @@ C<XS_unpack_foo_tPtr>.
 =item T_PACKEDARRAY
 
 T_PACKEDARRAY is similar to T_PACKED. In fact, the C<INPUT> (Perl
-to XSUB) typemap is indentical, but the C<OUTPUT> typemap passes
+to XSUB) typemap is identical, but the C<OUTPUT> typemap passes
 an additional argument to the C<XS_pack_$ntype> function. This
 third parameter indicates the number of elements in the output
 so that the function can handle C arrays sanely. The variable
@@ -612,7 +612,7 @@ is concerned. It just has to be in line with the declared variable.
 
 Of course, unless you know the number of elements in the
 C<sometype **> C array, within your XSUB, the return value from
-C<foo_t ** XS_unpack_foo_tPtrPtr(...)> will be hard to decypher.
+C<foo_t ** XS_unpack_foo_tPtrPtr(...)> will be hard to decipher.
 Since the details are all up to the XS author (the typemap user),
 there are several solutions, none of which particularly elegant.
 The most commonly seen solution has been to allocate memory for
@@ -620,7 +620,7 @@ N+1 pointers and assign C<NULL> to the (N+1)th to facilitate
 iteration.
 
 Alternatively, using a customized typemap for your purposes in
-the first place is probably preferrable.
+the first place is probably preferable.
 
 =item T_DATAUNIT