INN commit: trunk/doc/pod (hacking.pod)
INN Commit
rra at isc.org
Fri Jul 6 17:57:11 UTC 2012
Date: Friday, July 6, 2012 @ 10:57:10
Author: eagle
Revision: 9436
Reformat HACKING POD source for consistent margins
Modified:
trunk/doc/pod/hacking.pod
-------------+
hacking.pod | 311 ++++++++++++++++++++++++++++++----------------------------
1 file changed, 163 insertions(+), 148 deletions(-)
Modified: hacking.pod
===================================================================
--- hacking.pod 2012-07-06 17:54:06 UTC (rev 9435)
+++ hacking.pod 2012-07-06 17:57:10 UTC (rev 9436)
@@ -29,33 +29,33 @@
All INN code should be written expecting S<ANSI C> and POSIX. There is no
need to attempt to support pre-ANSI compilers, and ANSI-only features such
-as F<< <stdarg.h> >>, string concatenation, C<#elif>, and token pasting may be used
-freely. So far as possible, INN is written to attempt to be portable to
-any system new enough that someone is likely to want to run a news server
-on it, but whenever possible this portability should be provided by
-checking for standard behavior in F<configure> and supplying replacements for
-standard functions that are missing.
+as F<< <stdarg.h> >>, string concatenation, C<#elif>, and token pasting
+may be used freely. So far as possible, INN is written to attempt to be
+portable to any system new enough that someone is likely to want to run a
+news server on it, but whenever possible this portability should be
+provided by checking for standard behavior in F<configure> and supplying
+replacements for standard functions that are missing.
When there is a conflict between S<ANSI C> and C99, INN code should be
written expecting C99 and B<autoconf> used to patch up the differences.
Try to avoid using C<#ifdef> and the like in the middle of code as much as
possible. Instead, try to isolate the necessary portability bits and
-include them in B<libinn> or at least in conditional macros separate from the
-code. Trying to read code littered with conditional compilation
+include them in B<libinn> or at least in conditional macros separate from
+the code. Trying to read code littered with conditional compilation
directives is much more difficult.
The shell script F<configure> at the top level of the source tree is
generated by B<autoconf> from F<configure.ac> and the additional macros in
-the F<m4> directory, and F<include/config.h.in> is generated by B<autoheader>
-from F<configure.ac>. At configure time, F<configure> generates
-F<include/config.h> and several other files based on options it was given
-and what it discovers about the target system.
+the F<m4> directory, and F<include/config.h.in> is generated by
+B<autoheader> from F<configure.ac>. At configure time, F<configure>
+generates F<include/config.h> and several other files based on options it
+was given and what it discovers about the target system.
-All modifications to F<configure> should instead be made to F<configure.ac>.
-The B<autoconf> manual (available using C<info autoconf> if you have B<autoconf>
-and the GNU B<info> utilities installed on your system) is a valuable
-reference when making any modifications.
+All modifications to F<configure> should instead be made to
+F<configure.ac>. The B<autoconf> manual (available using C<info autoconf>
+if you have B<autoconf> and the GNU B<info> utilities installed on your
+system) is a valuable reference when making any modifications.
To regenerate F<configure>, just run C<autoconf>. To regenerate
F<include/config.h.in>, run C<autoheader>. Alternately, to regenerate
@@ -68,21 +68,23 @@
The supporting files for B<autoconf> are in the F<support> subdirectory,
including the files F<config.guess> and F<config.sub> to determine the
-system name and F<ltmain.sh> for libtool support. The latter file
-comes from the libtool distribution available from
-L<http://www.gnu.org/software/libtool/>; the canonical version of the former
-two are available from L<ftp://ftp.gnu.org/gnu/config/> (which currently
-redirects to L<http://git.savannah.gnu.org/gitweb/?p=config.git;a=tree>).
-In addition, F<m4/libtool.m4> is just a copy of F<libtool.m4> from the
-libtool distribution. (Using libtool without using B<automake> requires
-a few odd hacks.) New versions should be checked in periodically when
-available. There are no INN-specific modifications to those files except
-for F<ltmain.sh> which recognizes the additional B<-B> flag that INN's
-B<install-sh> script uses. This script should also be updated at the
-same time from L<http://git.savannah.gnu.org/gitweb/?p=automake.git;a=tree;f=lib>;
-it similarly contains local modifications in order to support
-the additional B<-B> flag, as well as a few other changes mentioned
-in a comment at the beginning of the file.
+system name and F<ltmain.sh> for libtool support. The latter file comes
+from the libtool distribution available from
+L<http://www.gnu.org/software/libtool/>; the canonical version of the
+former two are available from L<ftp://ftp.gnu.org/gnu/config/> (which
+currently redirects to
+L<http://git.savannah.gnu.org/gitweb/?p=config.git;a=tree>). In addition,
+F<m4/libtool.m4> is just a copy of F<libtool.m4> from the libtool
+distribution. (Using libtool without using B<automake> requires a few odd
+hacks.) New versions should be checked in periodically when available.
+There are no INN-specific modifications to those files except for
+F<ltmain.sh> which recognizes the additional B<-B> flag that INN's
+B<install-sh> script uses. This script should also be updated at the same
+time from
+L<http://git.savannah.gnu.org/gitweb/?p=automake.git;a=tree;f=lib>; it
+similarly contains local modifications in order to support the additional
+B<-B> flag, as well as a few other changes mentioned in a comment at the
+beginning of the file.
INN should not compile with libtool by default, only when requested, since
otherwise normal compilations are quite slow. (Using libtool is not
@@ -120,8 +122,9 @@
latest version of podlators. For versions of Perl earlier than 5.005,
you'll also need C<File::Spec> in F<modules/by-module/File>.
-S<podlators 1.25> or later will build INN's documentation without significant
-changes from the versions that are checked into the repository.
+S<podlators 1.25> or later will build INN's documentation without
+significant changes from the versions that are checked into the
+repository.
There are makefile rules in F<doc/pod/Makefile> to build all of the
documentation whose master form is POD; if you add additional
@@ -224,26 +227,27 @@
program that tests some part of INN, put it in a directory under F<tests>
named after the part of INN it's testing, and have it output first a line
containing the count of test cases in that file, and then for each test a
-line saying C<ok n> or C<not ok n> where C<n> is the test case number. (If a
-test is skipped for some reason, such as a test of an optional feature
-that wasn't compiled into INN, the test program should output C<ok n #
-skip>.) Add any rules necessary to build the test to F<tests/Makefile>
-(note that for simplicity it doesn't recurse into subdirectories) and make
-sure it creates an executable ending in F<.t>. Then add the name of the
-test to F<tests/TESTS>, without the F<.t> ending.
+line saying C<ok n> or C<not ok n> where C<n> is the test case number.
+(If a test is skipped for some reason, such as a test of an optional
+feature that wasn't compiled into INN, the test program should output C<ok
+n # skip>.) Add any rules necessary to build the test to
+F<tests/Makefile> (note that for simplicity it doesn't recurse into
+subdirectories) and make sure it creates an executable ending in F<.t>.
+Then add the name of the test to F<tests/TESTS>, without the F<.t> ending.
For C tests, you probably want to use the functions in F<libtest.c>
(prototypes in F<libtest.h>) to handle all of the output. For shell script
tests, see the existing tests for some helpful shell functions.
One naming convention: to distinguish more easily between for example
-F<lib/error.c> (the implementation) and F<tests/lib/error-t.c> (the test suite),
-we add F<-t> to the end of the test file names. So F<tests/lib/error-t.c> is
-the source that compiles into an executable F<tests/lib/error.t> which is run
-by putting a line in F<tests/TESTS> of just C<lib/error>.
+F<lib/error.c> (the implementation) and F<tests/lib/error-t.c> (the test
+suite), we add F<-t> to the end of the test file names. So
+F<tests/lib/error-t.c> is the source that compiles into an executable
+F<tests/lib/error.t> which is run by putting a line in F<tests/TESTS> of
+just C<lib/error>.
-Note that tests don't have to be written in C; in fact, F<lib/xmalloc.t> is
-just a shell script (that calls a supporting C program). Tests can be
+Note that tests don't have to be written in C; in fact, F<lib/xmalloc.t>
+is just a shell script (that calls a supporting C program). Tests can be
written in shell or Perl (but other languages should be avoided because
someone who wants to run the test suite may not have it) and just have to
follow the above output conventions.
@@ -252,25 +256,25 @@
=head1 Makefiles
-All INN makefiles include F<Makefile.global> at the top level, and only that
-makefile is a F<configure> substitution target. This has the disadvantage
-that F<configure>'s normal support for building in a tree outside of the
-source tree doesn't work, but it has the significant advantage of making
-F<configure> run much faster and allowing one to run C<make> in any subdirectory
-and pick up all the definitions and settings from the top level
-configuration.
+All INN makefiles include F<Makefile.global> at the top level, and only
+that makefile is a F<configure> substitution target. This has the
+disadvantage that F<configure>'s normal support for building in a tree
+outside of the source tree doesn't work, but it has the significant
+advantage of making F<configure> run much faster and allowing one to run
+C<make> in any subdirectory and pick up all the definitions and settings
+from the top level configuration.
-All INN makefiles should also set C<$(top)> to be the path to the top of the
-build directory (usually relative). This path is used to find various
+All INN makefiles should also set C<$(top)> to be the path to the top of
+the build directory (usually relative). This path is used to find various
programs like B<fixscript> and libtool so that the same macros (set in
F<Makefile.global>) can be used all over INN.
The format of INN's makefiles is mostly standardized; the best examples of
the format are probably F<frontends/Makefile> and F<backends/Makefile>, at
least for directories with lots of separate programs. The C<ALL> variable
-holds all the files that should be generated, C<EXTRA> those additional files
-that were generated by F<configure>, and C<SOURCES> the C source files for
-generating tag information.
+holds all the files that should be generated, C<EXTRA> those additional
+files that were generated by F<configure>, and C<SOURCES> the C source
+files for generating tag information.
There are a set of standard installation commands defined in make
variables by F<Makefile.global>, and these should be used for all file
@@ -295,21 +299,22 @@
INN comes with and installs a large number of different scripts, both
Bourne shell and Perl, and also comes with support for Tcl scripts
(although it doesn't come with any). Shell variables containing both
-F<configure>-time information and configuration information from F<inn.conf> are
-set by the B<innshellvars> support libraries, so the only system-specific
-configuration that should have to be done is fixing the right path to the
-interpreter and adding a line to load the appropriate B<innshellvars>.
+F<configure>-time information and configuration information from
+F<inn.conf> are set by the B<innshellvars> support libraries, so the only
+system-specific configuration that should have to be done is fixing the
+right path to the interpreter and adding a line to load the appropriate
+B<innshellvars>.
-F<support/fixscript>, built by F<configure>, does this. It takes a F<.in> file
-and generates the final script (removing the F<.in>) by fixing the path to
-the interpreter on the first line and replacing the second line, whatever
-it is, with code to load the B<innshellvars> appropriate for that
+F<support/fixscript>, built by F<configure>, does this. It takes a F<.in>
+file and generates the final script (removing the F<.in>) by fixing the
+path to the interpreter on the first line and replacing the second line,
+whatever it is, with code to load the B<innshellvars> appropriate for that
interpreter. (If invoked with B<-i>, it just fixes the interpreter path.)
-Scripts should use B<innshellvars> (via B<fixscript>) to get the right path and
-the right variables whenever possible, rather than having F<configure>
-substitute values in them. Any values needed at run-time should instead
-be available from all of the different B<innshellvars>.
+Scripts should use B<innshellvars> (via B<fixscript>) to get the right
+path and the right variables whenever possible, rather than having
+F<configure> substitute values in them. Any values needed at run-time
+should instead be available from all of the different B<innshellvars>.
As for Perl, the C<INN::Config> module has the same features as
F<innshellvars.pl> (only kept for compatibility reasons with old scripts
@@ -331,12 +336,13 @@
#include "config.h"
#include "clibrary.h"
-The first picks up all defines generated by B<autoconf> and is necessary for
-types that may not be present on all systems (I<uid_t>, I<pid_t>, I<size_t>,
-I<uint32_t>, and the like). It therefore should be included before any other
-headers that use those types, as well as to get general configuration
-information. It also includes F<inn/defines.h> and F<inn/options.h>, which
-pick up additional support macros and compile-time configuration.
+The first picks up all defines generated by B<autoconf> and is necessary
+for types that may not be present on all systems (I<uid_t>, I<pid_t>,
+I<size_t>, I<uint32_t>, and the like). It therefore should be included
+before any other headers that use those types, as well as to get general
+configuration information. It also includes F<inn/defines.h> and
+F<inn/options.h>, which pick up additional support macros and compile-time
+configuration.
The second is portably equivalent to:
@@ -354,12 +360,13 @@
provides macros that INN assumes are available but which weren't found,
and defines some additional portability things. Even if this is more
headers than the source file actually needs, it's generally better to just
-include F<clibrary.h> rather than trying to duplicate the B<autoconf>-driven
-hackery that it does to do things portably. The primary exception is for
-source files in F<lib> that only define a single function and are used for
-portability; those may want to include only F<config.h> so that they can
-be easily used in other projects that use B<autoconf>. F<config.h> is a
-fairly standard header name for this purpose.
+include F<clibrary.h> rather than trying to duplicate the
+B<autoconf>-driven hackery that it does to do things portably. The
+primary exception is for source files in F<lib> that only define a single
+function and are used for portability; those may want to include only
+F<config.h> so that they can be easily used in other projects that use
+B<autoconf>. F<config.h> is a fairly standard header name for this
+purpose.
F<clibrary.h> does also include F<config.h>, but it's somewhat poor form
to rely on this; it's better to explicitly list the header dependencies
@@ -370,16 +377,17 @@
F<include/portable> and familiarize yourself with them and use them where
appropriate.
-Another frequently included header file is F<inn/libinn.h>, which among other
-things defines xmalloc(), xrealloc(), xstrdup(), and xcalloc(), which are
-checked versions of the standard memory allocation routines that terminate
-the program if the memory allocation fails. These should generally always
-be used instead of the regular C versions. F<inn/libinn.h> also provides
-various other utility functions that are frequently used.
+Another frequently included header file is F<inn/libinn.h>, which among
+other things defines xmalloc(), xrealloc(), xstrdup(), and xcalloc(),
+which are checked versions of the standard memory allocation routines that
+terminate the program if the memory allocation fails. These should
+generally always be used instead of the regular C versions.
+F<inn/libinn.h> also provides various other utility functions that are
+frequently used.
-F<inn/paths.h> includes a wide variety of paths determined at configure time,
-both default paths to various parts of INN and paths to programs. Don't
-just use the default paths, though, if they're also configurable in
+F<inn/paths.h> includes a wide variety of paths determined at configure
+time, both default paths to various parts of INN and paths to programs.
+Don't just use the default paths, though, if they're also configurable in
F<inn.conf>; instead, call innconf_read() and use the global I<innconf>
structure.
@@ -391,8 +399,8 @@
and uninstalled header files; the latter are those headers that are used
only for compiling INN and aren't useful for users of INN's libraries
(such as F<clibrary.h>). All of the installed headers will live in
-F<include/inn> and be installed in a subdirectory named F<inn> in the configured
-F<include> directory. This conversion is still in progress.
+F<include/inn> and be installed in a subdirectory named F<inn> in the
+configured F<include> directory. This conversion is still in progress.
When writing header files, remember that C reserves all identifiers
beginning with two underscores and all identifiers beginning with an
@@ -404,10 +412,10 @@
Try to pay attention to the impact of a header file on the program
namespace, particularly for installed header files in F<include/inn>. All
-symbols defined by a header file should ideally begin with C<INN_>, C<inn_>, or
-some other unique prefix indicating the subsystem that symbol is part of,
-to avoid accidental conflicts with symbols defined by the program that
-uses that header file.
+symbols defined by a header file should ideally begin with C<INN_>,
+C<inn_>, or some other unique prefix indicating the subsystem that symbol
+is part of, to avoid accidental conflicts with symbols defined by the
+program that uses that header file.
=head1 Coding Style
@@ -425,9 +433,9 @@
=item *
-Write in regular S<ANSI C> whenever possible. Use the normal ANSI and POSIX
-constructs and use B<autoconf> or portability wrappers to fix things up
-beforehand so that the code itself can read like regular ANSI or POSIX
+Write in regular S<ANSI C> whenever possible. Use the normal ANSI and
+POSIX constructs and use B<autoconf> or portability wrappers to fix things
+up beforehand so that the code itself can read like regular ANSI or POSIX
code. Code should be written so that it works as expected on a modern
platform and is fixed up with portability tricks for older platforms, not
the other way around. You may assume an S<ANSI C> compiler.
@@ -457,22 +465,24 @@
=item *
-Avoid C<#ifdef> and friends whenever possible. Particularly avoid using them
-in the middle of code blocks. Try to hide all portability preprocessor
-magic in header files or in portability code in F<lib>. When something just
-has to be done two completely different ways depending on the platform or
-compile options or the like, try to abstract that functionality out into a
-generic function and provide two separate implementations using C<#ifdef>;
-then the main code can just call that function.
+Avoid C<#ifdef> and friends whenever possible. Particularly avoid using
+them in the middle of code blocks. Try to hide all portability
+preprocessor magic in header files or in portability code in F<lib>. When
+something just has to be done two completely different ways depending on
+the platform or compile options or the like, try to abstract that
+functionality out into a generic function and provide two separate
+implementations using C<#ifdef>; then the main code can just call that
+function.
If you do have to use preprocessor defines, note that if you always define
-them to either C<0> or C<1> (never use C<#define> without a second argument),
-you can use the preprocessor define in a regular if statement rather than
-using C<#if> or C<#ifdef>. Make use of this instead of C<#ifdef> when possible,
-since that way the compiler will still syntax-check the other branch for
-you and it makes it far easier to convert the code to use a run-time check
-if necessary. (Unfortunately, this trick can't be used if one branch may
-call functions unavailable on a particular platform.)
+them to either C<0> or C<1> (never use C<#define> without a second
+argument), you can use the preprocessor define in a regular if statement
+rather than using C<#if> or C<#ifdef>. Make use of this instead of
+C<#ifdef> when possible, since that way the compiler will still
+syntax-check the other branch for you and it makes it far easier to
+convert the code to use a run-time check if necessary. (Unfortunately,
+this trick can't be used if one branch may call functions unavailable on a
+particular platform.)
=item *
@@ -511,8 +521,8 @@
multiline comment. */
Comments before functions saying what they do are nice to have. In
-general, the RCS/SVN C<Id> tag is on the first line of each source file since
-it's useful to know when a file was last modified.
+general, the RCS/SVN C<Id> tag is on the first line of each source file
+since it's useful to know when a file was last modified.
=item *
@@ -529,8 +539,8 @@
=item *
-It's better to always put the body of an C<if> statement on a separate line,
-even if it's only a single line. In other words, write:
+It's better to always put the body of an C<if> statement on a separate
+line, even if it's only a single line. In other words, write:
if (p != NULL)
return p;
@@ -579,8 +589,8 @@
arguments to the called function, misidentifies some macro calls as being
type declarations, and fouls up long but simple case statements). It
would be excellent if someday we could just run all of INN's code through
-B<indent> routinely to enforce a consistant coding style, but B<indent> isn't
-quite ready for that.
+B<indent> routinely to enforce a consistant coding style, but B<indent>
+isn't quite ready for that.
For users of emacs cc-mode, use the "bsd" style but with:
@@ -618,28 +628,30 @@
Make sure that F<support/config.guess>, F<support/config.sub>,
F<support/install-sh>, F<support/ltmain.sh> and libtool m4 files
-(F<libtool.m4>, F<ltoptions.m4>, F<ltsugar.m4>, F<ltversion.m4>
-and F<lt~obsolete.m4>) are the latest versions. See the instructions
-in L<"Configuring and Portability"> for details on how to update these files.
+(F<libtool.m4>, F<ltoptions.m4>, F<ltsugar.m4>, F<ltversion.m4> and
+F<lt~obsolete.m4>) are the latest versions. See the instructions in
+L<"Configuring and Portability"> for details on how to update these files.
=item *
-Make sure that the latest version of C TAP Harness
-is used for the test suite. It is available from
+Make sure that the latest version of C TAP Harness is used for the test
+suite. It is available from
L<http://www.eyrie.org/~eagle/software/c-tap-harness/>. The file
F<runtests.c> should be updated. F<libtest.c>, F<libtest.h> and
-F<libtest.sh> come from F<tap/basic.c>, F<tap/basic.h> and F<tap/libtap.sh>
-respectively. Parts specific to INN should be kept during an update
-(especially sections relative to LIBTEST_NEW_FORMAT because the test suite
-has not yet been updated to use the new format of C TAP Harness).
+F<libtest.sh> come from F<tap/basic.c>, F<tap/basic.h> and
+F<tap/libtap.sh> respectively. Parts specific to INN should be kept
+during an update (especially sections relative to LIBTEST_NEW_FORMAT
+because the test suite has not yet been updated to use the new format of C
+TAP Harness).
=back
=item 2.
Make sure that F<samples/control.ctl> and F<samples/nocem.ctl> are in sync
-with the master version at L<ftp://ftp.isc.org/pub/usenet/CONFIG/control.ctl>
-and L<http://www.xs4all.nl/~rosalind/nocemreg/nocemreg.html>.
+with the master version at
+L<ftp://ftp.isc.org/pub/usenet/CONFIG/control.ctl> and
+L<http://www.xs4all.nl/~rosalind/nocemreg/nocemreg.html>.
=item 3.
@@ -663,7 +675,8 @@
and can be done a little while before the C<.0> release of that major
release.
- svn copy -r ZZZZ -m "Branch Y.Y.0 release." file:///srv/svn/inn/trunk file:///srv/svn/inn/branches/Y.Y
+ svn copy -r ZZZZ -m "Branch Y.Y.0 release." \
+ file:///srv/svn/inn/trunk file:///srv/svn/inn/branches/Y.Y
Then, remove the first paragraph in F<doc/pod/readme.pod> which deals
with development versions.
@@ -678,13 +691,13 @@
=item 7.
-Run C<make release> for a final release, C<support/mksnapshot BETA b1>
-for the first beta version of a new release, or C<support/mksnapshot RC rc1>
+Run C<make release> for a final release, C<support/mksnapshot BETA b1> for
+the first beta version of a new release, or C<support/mksnapshot RC rc1>
for the first release candidate version of a new release. Note that you
need to have a copy of B<svn2cl> from L<http://arthurdejong.org/svn2cl/>
-to do this; at least version 0.7 is required. Start the F<ChangeLog> at the
-time of the previous release. (Eventually, the script will be smart enough
-to do this for you.)
+to do this; at least version 0.7 is required. Start the F<ChangeLog> at
+the time of the previous release. (Eventually, the script will be smart
+enough to do this for you.)
Check that the F<ChangeLog> file is correct; otherwise, regenerate it or
manually edit it. Then run again C<make release> or any other command
@@ -718,11 +731,11 @@
=item 11.
Move the release into the public area of the ftp site and update the
-F<inn.tar.gz> link. Also put the diff and the MD5 checksum on the ftp site
-and update the F<inn.tar.gz.md5> link. Contact the ISC folks to get the
-release PGP-signed and the ISC web site updated (the relevant contact is
-C<web-request> instead of C<webmaster>). Update the F<inn.tar.gz.asc> link.
-Possibly move older releases off into the F<OLD> directory.
+F<inn.tar.gz> link. Also put the diff and the MD5 checksum on the ftp
+site and update the F<inn.tar.gz.md5> link. Contact the ISC folks to get
+the release PGP-signed and the ISC web site updated (the relevant contact
+is C<web-request> instead of C<webmaster>). Update the F<inn.tar.gz.asc>
+link. Possibly move older releases off into the F<OLD> directory.
=item 12.
@@ -735,15 +748,16 @@
Tag the checked-out tree that was used for generating the release with a
release tag by copying it to F<tags> in Subversion.
- svn copy -r ZZZZ -m "Tag Y.Y.Y release." file:///srv/svn/inn/branches/Y.Y file:///srv/svn/inn/tags/Y.Y.Y
+ svn copy -r ZZZZ -m "Tag Y.Y.Y release." \
+ file:///srv/svn/inn/branches/Y.Y file:///srv/svn/inn/tags/Y.Y.Y
=item 14.
Bump revision numbers to reflect the one of the following release,
-especially in F<doc/pod/install.pod> and F<doc/pod/readme.pod>
-for major releases, F<configure.ac> and F<Makefile.global.in>
-for both minor and major releases. The release versions in the
-Trac wiki should also be updated.
+especially in F<doc/pod/install.pod> and F<doc/pod/readme.pod> for major
+releases, F<configure.ac> and F<Makefile.global.in> for both minor and
+major releases. The release versions in the Trac wiki should also be
+updated.
=back
@@ -766,7 +780,8 @@
The archives for the USEFOR IETF working group, the working group for the
S<RFC 1036> replacement (the format of Usenet articles), now published as
S<RFC 5536> and S<RFC 5537>. Also contains a lot of references to other
-relevant work. Another useful link is L<http://www.eyrie.org/~eagle/usefor/>.
+relevant work. Another useful link is
+L<http://www.eyrie.org/~eagle/usefor/>.
=item L<http://www.mibsoftware.com/userkt/inn/dev/>
More information about the inn-committers
mailing list