I<see> that the community efforts really work. So after each of his
sync points, you are to 'make test' to check if everything is still
in working order. If it is, you do 'make ok', which will send an OK
-report to perlbug@perl.org. (If you do not have access to a mailer
+report to I<perlbug@perl.org>. (If you do not have access to a mailer
from the system you just finished successfully 'make test', you can
do 'make okfile', which creates the file C<perl.ok>, which you can
than take to your favourite mailer and mail yourself).
=head2 Perlbug administration
-There is a single remote administrative interface for modifying bug status,
-category, open issues etc. using the B<RT> I<bugtracker> system, maintained
-by I<Robert Spier>. Become an administrator, and close any bugs you can get
+There is a single remote administrative interface for modifying bug status,
+category, open issues etc. using the B<RT> bugtracker system, maintained
+by Robert Spier. Become an administrator, and close any bugs you can get
your sticky mitts on:
- http://rt.perl.org
-
-The bugtracker mechanism for B<perl5> bugs in particular is at:
-
- http://bugs6.perl.org/perlbug
+ http://rt.perl.org/rt3/
To email the bug system administrators:
"perlbug-admin" <perlbug-admin@perl.org>
-
=head2 Submitting patches
Always submit patches to I<perl5-porters@perl.org>. If you're
but context diffs are accepted. Do not send RCS-style diffs or diffs
without context lines. More information is given in the
I<Porting/patching.pod> file in the Perl source distribution. Please
-patch against the latest B<development> version (e.g., if you're
-fixing a bug in the 5.005 track, patch against the latest 5.005_5x
-version). Only patches that survive the heat of the development
+patch against the latest B<development> version. (e.g., even if you're
+fixing a bug in the 5.8 track, patch against the latest B<development>
+version rsynced from rsync://public.activestate.com/perl-current/ )
+
+If changes are accepted, they are applied to the development branch. Then
+the 5.8 pumpking decides which of those patches is to be backported to the
+maint branch. Only patches that survive the heat of the development
branch get applied to maintenance versions.
-Your patch should update the documentation and test suite. See
+Your patch should also update the documentation and test suite. See
L<Writing a test>.
+Patching documentation also follows the same order: if accepted, a patch
+is first applied to B<development>, and if relevant then it's backported
+to B<maintenance>. (With an exception for some patches that document
+behaviour that only appears in the maintenance branch, but which has
+changed in the development version.)
+
To report a bug in Perl, use the program I<perlbug> which comes with
Perl (if you can't get Perl to work, send mail to the address
I<perlbug@perl.org> or I<perlbug@perl.com>). Reporting bugs through
I<perlbug> feeds into the automated bug-tracking system, access to
-which is provided through the web at http://bugs.perl.org/ . It
+which is provided through the web at http://rt.perl.org/rt3/ . It
often pays to check the archives of the perl5-porters mailing list to
see whether the bug you're reporting has been reported before, and if
so whether it was considered a bug. See above for the location of
The CPAN testers ( http://testers.cpan.org/ ) are a group of
volunteers who test CPAN modules on a variety of platforms. Perl
-Smokers ( http://archives.develooper.com/daily-build@perl.org/ )
-automatically tests Perl source releases on platforms with various
+Smokers ( http://www.nntp.perl.org/group/perl.daily-build )
+automatically test Perl source releases on platforms with various
configurations. Both efforts welcome volunteers.
It's a good idea to read and lurk for a while before chipping in.
=item The perl5-porters FAQ
-This should be available from http://simon-cozens.org/writings/p5p-faq ;
-alternatively, you can get the FAQ emailed to you by sending mail to
-C<perl5-porters-faq@perl.org>. It contains hints on reading perl5-porters,
-information on how perl5-porters works and how Perl development in general
-works.
+This should be available from http://dev.perl.org/perl5/docs/p5p-faq.html .
+It contains hints on reading perl5-porters, information on how
+perl5-porters works and how Perl development in general works.
=back
analysis of Java code, but later the cpd part of it was extended to
parse also C and C++.
-Download the pmd-X.y.jar from the SourceForge site, and then run
-it on source code thusly:
+Download the pmd-bin-X.Y.zip () from the SourceForge site, extract the
+pmd-X.Y.jar from it, and then run that on source code thusly:
java -cp pmd-X.Y.jar net.sourceforge.pmd.cpd.CPD --minimum-tokens 100 --files /some/where/src --language c > cpd.txt
The C<-Wall> is by default on.
-The C<-ansi> (and its sidekick, C<-pedantic>) would be nice to be
-on always, but unfortunately they are not safe on all platforms,
-they can for example cause fatal conflicts with the system headers
-(Solaris being a prime example). The C<cflags> frontend selects
-C<-ansi -pedantic> for the platforms where they are known to be safe.
+The C<-ansi> (and its sidekick, C<-pedantic>) would be nice to be on
+always, but unfortunately they are not safe on all platforms, they can
+for example cause fatal conflicts with the system headers (Solaris
+being a prime example). If Configure C<-Dgccansipedantic> is used,
+the C<cflags> frontend selects C<-ansi -pedantic> for the platforms
+where they are known to be safe.
Starting from Perl 5.9.4 the following extra flags are added:
C<-Wstrict-prototypes>
-=item *
-
=back
The C<-Wtraditional> is another example of the annoying tendency of
Compiling with threading (-Duseithreads) completely rewrites
the function prototypes of Perl. You better try your changes
-with that. Related to this is the difference between "Perl_"-less
+with that. Related to this is the difference between "Perl_-less"
and "Perl_-ly" APIs, for example:
Perl_sv_setiv(aTHX_ ...);
sv_setiv(...);
-The first one explicitly passes in the context, which is needed for
-e.g. threaded builds. The second one does that implicitly; do not get
-them mixed.
+The first one explicitly passes in the context, which is needed for e.g.
+threaded builds. The second one does that implicitly; do not get them
+mixed. If you are not passing in a aTHX_, you will need to do a dTHX
+(or a dVAR) as the first thing in the function.
See L<perlguts/"How multiple interpreters and concurrency are supported">
for further discussion about context.
Not compiling with -DDEBUGGING
The DEBUGGING define exposes more code to the compiler,
-therefore more ways for things to go wrong.
+therefore more ways for things to go wrong. You should try it.
+
+=item *
+
+Introducing (non-read-only) globals
+
+Do not introduce any modifiable globals, truly global or file static.
+They are bad form and complicate multithreading and other forms of
+concurrency. The right way is to introduce them as new interpreter
+variables, see F<intrpvar.h> (at the very end for binary compatibility).
+
+Introducing read-only (const) globals is okay, as long as you verify
+with e.g. C<nm libperl.a|egrep -v ' [TURtr] '> (if your C<nm> has
+BSD-style output) that the data you added really is read-only.
+(If it is, it shouldn't show up in the output of that command.)
+
+If you want to have static strings, make them constant:
+
+ static const char etc[] = "...";
+
+If you want to have arrays of constant strings, note carefully
+the right combination of C<const>s:
+
+ static const char * const yippee[] =
+ {"hi", "ho", "silver"};
+
+There is a way to completely hide any modifiable globals (they are all
+moved to heap), the compilation setting C<-DPERL_GLOBAL_STRUCT_PRIVATE>.
+It is not normally used, but can be used for testing, read more
+about it in L<perlguts/"Background and PERL_IMPLICIT_CONTEXT">.
=item *
The new shiny result of either genuine new functionality or your
arduous refactoring is now ready and correctly exported. So what
-could possibly be wrong?
+could possibly go wrong?
Maybe simply that your function did not need to be exported in the
first place. Perl has a long and not so glorious history of exporting
=back
-=head Portability problems
+=head2 Portability problems
The following are common causes of compilation and/or execution
failures, not common to Perl as such. The C FAQ is good bedtime
-reading. Please test your changes with as many C compilers as
-possible -- we will, anyway, and it's nice to save oneself from
-public embarrassment.
+reading. Please test your changes with as many C compilers and
+platforms as possible -- we will, anyway, and it's nice to save
+oneself from public embarrassment.
+
+If using gcc, you can add the C<-std=c89> option which will hopefully
+catch most of these unportabilities. (However it might also catch
+incompatibilities in your system's header files.)
+
+Use the Configure C<-Dgccansipedantic> flag to enable the gcc
+C<-ansi -pedantic> flags which enforce stricter ANSI rules.
+
+If using the C<gcc -Wall> note that not all the possible warnings
+(like C<-Wunitialized>) are given unless you also compile with C<-O>.
+
+Note that if using gcc, starting from Perl 5.9.5 the Perl core source
+code files (the ones at the top level of the source code distribution,
+but not e.g. the extensions under ext/) are automatically compiled
+with as many as possible of the C<-std=c89>, C<-ansi>, C<-pedantic>,
+and a selection of C<-W> flags (see cflags.SH).
+
+Also study L<perlport> carefully to avoid any bad assumptions
+about the operating system, filesystems, and so forth.
+
+You may once in a while try a "make microperl" to see whether we
+can still compile Perl with just the bare minimum of interfaces.
+(See README.micro.)
+
+Do not assume an operating system indicates a certain compiler.
=over 4
{
IV i = (IV)p;
-Either are bad, and broken, and unportable. Use the PTR2IV()
+Both are bad, and broken, and unportable. Use the PTR2IV()
macro that does it right. (Likewise, there are PTR2UV(), PTR2NV(),
INT2PTR(), and NUM2PTR().)
=item *
+Casting between data function pointers and data pointers
+
Technically speaking casting between function pointers and data
pointers is unportable and undefined, but practically speaking
it seems to work, but you should use the FPTR2DPTR() and DPTR2FPTR()
-macros.
+macros. Sometimes you can also play games with unions.
=item *
shorts are 64 bits. This is all legal according to the C standard.
(In other words, "long long" is not a portable way to specify 64 bits,
and "long long" is not even guaranteed to be any wider than "long".)
-Use definitions like IVSIZE, I32SIZE, and so forth.
+
+Instead, use the definitions IV, UV, IVSIZE, I32SIZE, and so forth.
+Avoid things like I32 because they are B<not> guaranteed to be
+I<exactly> 32 bits, they are I<at least> 32 bits, nor are they
+guaranteed to be B<int> or B<long>. If you really explicitly need
+64-bit variables, use I64 and U64, but only if guarded by HAS_QUAD.
=item *
Assuming one can dereference any type of pointer for any type of data
char *p = ...;
- long pony = *p;
+ long pony = *p; /* BAD */
Many platforms, quite rightly so, will give you a core dump instead
of a pony if the p happens not be correctly aligned.
Lvalue casts
- (int)*p = ...;
+ (int)*p = ...; /* BAD */
Simply not portable. Get your lvalue to be of the right type,
-or maybe use temporary variables.
+or maybe use temporary variables, or dirty tricks with unions.
=item *
-Using //-comments
-
- // This function bamfoodles the zorklator.
+Assume B<anything> about structs (especially the ones you
+don't control, like the ones coming from the system headers)
-That is C99 or C++. Perl is C89. Using the //-comments is silently
-allowed by many C compilers but cranking up the ANSI strictness (which
-we like to do) causes the compilation to fail.
+=over 8
=item *
-Mixing declarations and code
+That a certain field exists in a struct
- void zorklator()
- {
- int n = 3;
- set_zorkmids(n);
- int q = 4;
+=item *
-That is C99 or C++. Some compilers allow that, but you shouldn't.
+That no other fields exist besides the ones you know of
=item *
-Mixing signed char pointers with unsigned char pointers
+That a field is of certain signedness, sizeof, or type
- int foo(char *s) { ... }
- ...
- unsigned char *t = ...; /* Or U8* t = ... */
- foo(t);
+=item *
-While this is legal practice, it is certainly dubious, and downright
-fatal in at least one platform: for example VMS cc considers this a
-fatal error. One cause for people often making this mistake is that a
-"naked char" and therefore deferencing a "naked char pointer" have an
-undefined sign: it depends on the compilers and the platform whether
-the result is signed or unsigned.
+That the fields are in a certain order
+
+=over 8
=item *
-Macros that have string constants and their arguments as substrings of
-the string constants
+While C guarantees the ordering specified in the struct definition,
+between different platforms the definitions might differ
- #define FOO(n) printf("number = %d\n", n)
- FOO(10);
+=back
-Pre-ANSI semantics for that was equivalent to
+=item *
- printf("10umber = %d\10");
+That the sizeof(struct) or the alignments are the same everywhere
-which is probably not what you were expecting. Unfortunately at
-least one C compiler does real backward compatibility here, in AIX
-that is what still happens even though the rest of the AIX compiler
-is very happily C89.
+=over 8
-=back
+=item *
-=head2 Security problems
+There might be padding bytes between the fields to align the fields -
+the bytes can be anything
-Last but not least, here are various tips for safer coding.
+=item *
-=over 4
+Structs are required to be aligned to the maximum alignment required
+by the fields - which for native types is for usually equivalent to
+sizeof() of the field
+
+=back
+
+=back
=item *
-Do not use gets()
+Mixing #define and #ifdef
-Or we will publicly ridicule you. Seriously.
+ #define BURGLE(x) ... \
+ #ifdef BURGLE_OLD_STYLE /* BAD */
+ ... do it the old way ... \
+ #else
+ ... do it the new way ... \
+ #endif
+
+You cannot portably "stack" cpp directives. For example in the above
+you need two separate BURGLE() #defines, one for each #ifdef branch.
=item *
-Do not use strcpy() or strcat()
+Adding stuff after #endif or #else
-Where there still linger some uses of these in the Perl source code,
-we have inspected them for safety and are very, very ashamed of them,
-and plan to get rid of them. In places where there are strlcpy()
-and strlcat() we prefer to use them, and there is a plan to integrate
-the strlcpy/strlcat implementation of INN.
+ #ifdef SNOSH
+ ...
+ #else !SNOSH /* BAD */
+ ...
+ #endif SNOSH /* BAD */
-=item *
+The #endif and #else cannot portably have anything non-comment after
+them. If you want to document what is going (which is a good idea
+especially if the branches are long), use (C) comments:
-Do not use sprintf() or vsprintf()
+ #ifdef SNOSH
+ ...
+ #else /* !SNOSH */
+ ...
+ #endif /* SNOSH */
-Use my_snprintf() and my_vnsprintf() instead, which will try to use
-snprintf() and vsnprintf() if those safer APIs are available.
+The gcc option C<-Wendif-labels> warns about the bad variant
+(by default on starting from Perl 5.9.4).
-=back
+=item *
-=head2 Common problems when patching Perl source code
+Having a comma after the last element of an enum list
-Perl source plays by ANSI C89 rules: no C99 (or C++) extensions. In
-some cases we have to take pre-ANSI requirements into consideration.
-You don't care about some particular platform having broken Perl?
-I hear there is still a strong demand for J2EE programmers.
+ enum color {
+ CERULEAN,
+ CHARTREUSE,
+ CINNABAR, /* BAD */
+ };
-=head2 Perl environment problems
+is not portable. Leave out the last comma.
-=over 4
+Also note that whether enums are implicitly morphable to ints
+varies between compilers, you might need to (int).
=item *
-Not compiling with threading
+Using //-comments
-Compiling with threading (-Duseithreads) completely rewrites
-the function prototypes of Perl. You better try your changes
-with that. Related to this is the difference between "Perl_"-less
-and "Perl_-ly" APIs, for example:
+ // This function bamfoodles the zorklator. /* BAD */
- Perl_sv_setiv(aTHX_ ...);
- sv_setiv(...);
+That is C99 or C++. Perl is C89. Using the //-comments is silently
+allowed by many C compilers but cranking up the ANSI C89 strictness
+(which we like to do) causes the compilation to fail.
-The first one explicitly passes in the context, which is needed for
-e.g. threaded builds. The second one does that implicitly; do not get
-them mixed.
+=item *
-See L<perlguts/"How multiple interpreters and concurrency are supported">
-for further discussion about context.
+Mixing declarations and code
-=item *
+ void zorklator()
+ {
+ int n = 3;
+ set_zorkmids(n); /* BAD */
+ int q = 4;
-Not compiling with -DDEBUGGING
+That is C99 or C++. Some C compilers allow that, but you shouldn't.
-The DEBUGGING define exposes more code to the compiler,
-therefore more ways for things to go wrong.
+The gcc option C<-Wdeclaration-after-statements> scans for such problems
+(by default on starting from Perl 5.9.4).
=item *
-Not exporting your new function
+Introducing variables inside for()
-Some platforms (Win32, AIX, VMS, OS/2, to name a few) require any
-function that is part of the public API (the shared Perl library)
-to be explicitly marked as exported. See the discussion about
-F<embed.pl> in L<perlguts>.
+ for(int i = ...; ...; ...) { /* BAD */
+
+That is C99 or C++. While it would indeed be awfully nice to have that
+also in C89, to limit the scope of the loop variable, alas, we cannot.
=item *
-Exporting your new function
+Mixing signed char pointers with unsigned char pointers
-The new shiny result of either genuine new functionality or your
-arduous refactoring is now ready and correctly exported. So what
-could possibly be wrong?
+ int foo(char *s) { ... }
+ ...
+ unsigned char *t = ...; /* Or U8* t = ... */
+ foo(t); /* BAD */
-Maybe simply that your function did not need to be exported in the
-first place. Perl has a long and not so glorious history of exporting
-functions that it should not have.
+While this is legal practice, it is certainly dubious, and downright
+fatal in at least one platform: for example VMS cc considers this a
+fatal error. One cause for people often making this mistake is that a
+"naked char" and therefore dereferencing a "naked char pointer" have
+an undefined signedness: it depends on the compiler and the flags of
+the compiler and the underlying platform whether the result is signed
+or unsigned. For this very same reason using a 'char' as an array
+index is bad.
-If the function is used only inside one source code file, make it
-static. See the discussion about F<embed.pl> in L<perlguts>.
+=item *
-If the function is used across several files, but intended only for
-Perl's internal use (and this should be the common case), do not
-export it to the public API. See the discussion about F<embed.pl>
-in L<perlguts>.
+Macros that have string constants and their arguments as substrings of
+the string constants
-=back
+ #define FOO(n) printf("number = %d\n", n) /* BAD */
+ FOO(10);
-=head Portability problems
+Pre-ANSI semantics for that was equivalent to
-The following are common causes of compilation and/or execution
-failures, not common to Perl as such. The C FAQ is good bedtime
-reading. Please test your changes with as many C compilers as
-possible -- we will, anyway, and it's nice to save oneself from
-public embarrassment.
+ printf("10umber = %d\10");
-=over 4
+which is probably not what you were expecting. Unfortunately at least
+one reasonably common and modern C compiler does "real backward
+compatibility" here, in AIX that is what still happens even though the
+rest of the AIX compiler is very happily C89.
=item *
-Casting pointers to integers or casting integers to pointers
+Using printf formats for non-basic C types
- void castaway(U8* p)
- {
- IV i = p;
+ IV i = ...;
+ printf("i = %d\n", i); /* BAD */
-or
+While this might by accident work in some platform (where IV happens
+to be an C<int>), in general it cannot. IV might be something larger.
+Even worse the situation is with more specific types (defined by Perl's
+configuration step in F<config.h>):
- void castaway(U8* p)
- {
- IV i = (IV)p;
+ Uid_t who = ...;
+ printf("who = %d\n", who); /* BAD */
-Either are bad, and broken, and unportable. Use the PTR2IV()
-macro that does it right. (Likewise, there are PTR2UV(), PTR2NV(),
-INT2PTR(), and NUM2PTR().)
+The problem here is that Uid_t might be not only not C<int>-wide
+but it might also be unsigned, in which case large uids would be
+printed as negative values.
-=item *
+There is no simple solution to this because of printf()'s limited
+intelligence, but for many types the right format is available as
+with either 'f' or '_f' suffix, for example:
-Technically speaking casting between function pointers and data
-pointers is unportable and undefined, but practically speaking
-it seems to work, but you should use the FPTR2DPTR() and DPTR2FPTR()
-macros.
+ IVdf /* IV in decimal */
+ UVxf /* UV is hexadecimal */
-=item *
+ printf("i = %"IVdf"\n", i); /* The IVdf is a string constant. */
-Assuming sizeof(int) == sizeof(long)
+ Uid_t_f /* Uid_t in decimal */
-There are platforms where longs are 64 bits, and platforms where ints
-are 64 bits, and while we are out to shock you, even platforms where
-shorts are 64 bits. This is all legal according to the C standard.
-(In other words, "long long" is not a portable way to specify 64 bits,
-and "long long" is not even guaranteed to be any wider than "long".)
-Use definitions like IVSIZE, I32SIZE, and so forth.
+ printf("who = %"Uid_t_f"\n", who);
-=item *
+Or you can try casting to a "wide enough" type:
-Assuming one can dereference any type of pointer for any type of data
+ printf("i = %"IVdf"\n", (IV)something_very_small_and_signed);
- char *p = ...;
- long pony = *p;
+Also remember that the C<%p> format really does require a void pointer:
-Many platforms, quite rightly so, will give you a core dump instead
-of a pony if the p happens not be correctly aligned.
+ U8* p = ...;
+ printf("p = %p\n", (void*)p);
+
+The gcc option C<-Wformat> scans for such problems.
=item *
-Lvalue casts
+Blindly using variadic macros
- (int)*p = ...;
+gcc has had them for a while with its own syntax, and C99 brought
+them with a standardized syntax. Don't use the former, and use
+the latter only if the HAS_C99_VARIADIC_MACROS is defined.
-Simply not portable. Get your lvalue to be of the right type,
-or maybe use temporary variables.
+=item *
+
+Blindly passing va_list
+
+Not all platforms support passing va_list to further varargs (stdarg)
+functions. The right thing to do is to copy the va_list using the
+Perl_va_copy() if the NEED_VA_COPY is defined.
=item *
-Using //-comments
+Using gcc statement expressions
- // This function bamfoodles the zorklator.
+ val = ({...;...;...}); /* BAD */
-That is C99 or C++. Perl is C89. Using the //-comments is silently
-allowed by many C compilers but cranking up the ANSI strictness (which
-we like to do) causes the compilation to fail.
+While a nice extension, it's not portable. The Perl code does
+admittedly use them if available to gain some extra speed
+(essentially as a funky form of inlining), but you shouldn't.
=item *
-Mixing declarations and code
+Binding together several statements
- void zorklator()
- {
- int n = 3;
- set_zorkmids(n);
- int q = 4;
+Use the macros STMT_START and STMT_END.
-That is C99 or C++. Some compilers allow that, but you shouldn't.
+ STMT_START {
+ ...
+ } STMT_END
=item *
-Mixing signed char pointers with unsigned char pointers
+Testing for operating systems or versions when should be testing for features
- int foo(char *s) { ... }
- ...
- unsigned char *t = ...; /* Or U8* t = ... */
- foo(t);
+ #ifdef __FOONIX__ /* BAD */
+ foo = quux();
+ #endif
-While this is legal practice, it is certainly dubious, and downright
-fatal in at least one platform: for example VMS cc considers this a
-fatal error. One cause for people often making this mistake is that a
-"naked char" and therefore deferencing a "naked char pointer" have an
-undefined sign: it depends on the compilers and the platform whether
-the result is signed or unsigned.
+Unless you know with 100% certainty that quux() is only ever available
+for the "Foonix" operating system B<and> that is available B<and>
+correctly working for B<all> past, present, B<and> future versions of
+"Foonix", the above is very wrong. This is more correct (though still
+not perfect, because the below is a compile-time check):
-=item *
+ #ifdef HAS_QUUX
+ foo = quux();
+ #endif
-Macros that have string constants and their arguments as substrings of
-the string constants
+How does the HAS_QUUX become defined where it needs to be? Well, if
+Foonix happens to be UNIXy enought to be able to run the Configure
+script, and Configure has been taught about detecting and testing
+quux(), the HAS_QUUX will be correctly defined. In other platforms,
+the corresponding configuration step will hopefully do the same.
- #define FOO(n) printf("number = %d\n", n)
- FOO(10);
+In a pinch, if you cannot wait for Configure to be educated,
+or if you have a good hunch of where quux() might be available,
+you can temporarily try the following:
-Pre-ANSI semantics for that was equivalent to
+ #if (defined(__FOONIX__) || defined(__BARNIX__))
+ # define HAS_QUUX
+ #endif
- printf("10umber = %d\10");
+ ...
+
+ #ifdef HAS_QUUX
+ foo = quux();
+ #endif
-which is probably not what you were expecting. Unfortunately at
-least one C compiler does real backward compatibility here, in AIX
-that is what still happens even though the rest of the AIX compiler
-is very happily C89.
+But in any case, try to keep the features and operating systems separate.
=back
=item *
-Do not use strcpy() or strcat()
+Do not use strcpy() or strcat() or strncpy() or strncat()
-Where there still linger some uses of these in the Perl source code,
-we have inspected them for safety and are very, very ashamed of them,
-and plan to get rid of them. In places where there are strlcpy()
-and strlcat() we prefer to use them, and there is a plan to integrate
-the strlcpy/strlcat implementation of INN.
+Use my_strlcpy() and my_strlcat() instead: they either use the native
+implementation, or Perl's own implementation (borrowed from the public
+domain implementation of INN).
=item *
Do not use sprintf() or vsprintf()
-Use my_snprintf() and my_vnsprintf() instead, which will try to use
-snprintf() and vsnprintf() if those safer APIs are available.
+If you really want just plain byte strings, use my_snprintf()
+and my_vsnprintf() instead, which will try to use snprintf() and
+vsnprintf() if those safer APIs are available. If you want something
+fancier than a plain byte string, use SVs and Perl_sv_catpvf().
=back
is a good sign of these. Fixing these leaks is non-trivial,
unfortunately, but they must be fixed eventually.
+B<NOTE 4>: L<DynaLoader> will not clean up after itself completely
+unless Perl is built with the Configure option
+C<-Accflags=-DDL_UNLOAD_ALL_AT_EXIT>.
+
=head2 Rational Software's Purify
Purify is a commercial tool that is helpful in identifying
=back
-If you can do these things, you've started on the long road to Perl porting.
+If you can do these things, you've started on the long road to Perl porting.
Thanks for wanting to help make Perl better - and happy hacking!
=head1 AUTHOR
This document was written by Nathan Torkington, and is maintained by
the perl5-porters mailing list.
-
projects / p5sagit/p5-mst-13.2.git / blobdiff