changeset 5239:9056ec9c4b2b

skeleton manual
author Karl Berry <karl@freefriends.org>
date Sun, 19 Sep 2004 13:17:06 +0000
parents ea357a6f13d3
children afeb36cffdf0
files doc/Makefile doc/gnulib.texi doc/xalloc.texi
diffstat 3 files changed, 220 insertions(+), 39 deletions(-) [+]
line wrap: on
line diff
new file mode 100644
--- /dev/null
+++ b/doc/Makefile
@@ -0,0 +1,15 @@
+# $Id: Makefile,v 1.1 2004-09-19 13:17:06 karl Exp $
+# Makefile for gnulib doc.  
+# Copyright (C) 2004 Free Software Foundation, Inc.
+#
+# Copying and distribution of this file, with or without modification,
+# are permitted in any medium without royalty provided the copyright
+# notice and this notice are preserved.
+
+doc = gnulib
+
+TEXI2HTML = $(MAKEINFO) --no-split --html
+%.html: %.texi
+	$(TEXI2HTML) -o $@ $< 
+
+all: $(doc).info $(doc).html $(doc).dvi 
new file mode 100644
--- /dev/null
+++ b/doc/gnulib.texi
@@ -0,0 +1,205 @@
+\input texinfo   @c -*-texinfo-*-
+@comment $Id: gnulib.texi,v 1.1 2004-09-19 13:17:06 karl Exp $
+@comment %**start of header
+@setfilename gnulib.info
+@settitle GNU Gnulib
+@syncodeindex pg cp
+@syncodeindex fn cp
+@comment %**end of header
+
+@set UPDATED $Date: 2004-09-19 13:17:06 $
+
+@copying
+This manual is for GNU Gnulib (updated @value{UPDATED}),
+which is a library of common routines intended to be shared at the
+source level.
+
+Copyright @copyright{} 2004 Free Software Foundation, Inc.
+
+@quotation
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.1 or
+any later version published by the Free Software Foundation; with no
+Invariant Sections, with the Front-Cover Texts being ``A GNU Manual,''
+and with the Back-Cover Texts as in (a) below.  A copy of the
+license is included in the section entitled ``GNU Free Documentation
+License.''
+
+(a) The FSF's Back-Cover Text is: ``You have freedom to copy and modify
+this GNU Manual, like GNU software.  Copies published by the Free
+Software Foundation raise funds for GNU development.''
+@end quotation
+@end copying
+
+@dircategory Software development
+@direntry
+* gnulib: (gnulib).             Source files to share among distributions.
+@end direntry
+
+@titlepage
+@title GNU Gnulib
+@subtitle updated @value{UPDATED}
+@author @email{bug-gnulib@@gnu.org}
+@page
+@vskip 0pt plus 1filll
+@insertcopying
+@end titlepage
+
+@contents
+
+@ifnottex
+@node Top
+@top GNU Gnulib
+
+@insertcopying
+@end ifnottex
+
+@menu
+* Gnulib::
+* Invoking gnulib-tool::
+* Copying This Manual::
+* Index::
+@end menu
+
+
+@node Gnulib
+@chapter Gnulib
+
+This is not a real manual.  It's just a place to store random notes
+until someone (you?) gets around to actually writing a manual.
+
+Getting started:
+
+@itemize
+@item Gnulib is hosted at Savannah:
+      @url{http://savannah.gnu.org/projects/gnulib}.  Get the sources
+      through CVS from there.
+@item The Gnulib home page:
+      @url{http://www.gnu.org/software/gnulib/}.
+@end itemize
+
+@menu
+* Comments::
+* ctime::
+* inet_ntoa::
+* Out of memory handling::
+@end menu
+
+@node Comments
+@section Comments
+
+@cindex comments describing functions
+@cindex describing functions, locating
+Where to put comments describing functions: Because of risk of
+divergence, we prefer to keep most function describing comments in
+only one place: just above the actual function definition.  Some
+people prefer to put that documentation in the .h file.  In any case,
+it should appear in just one place unless you can ensure that the
+multiple copies will always remain identical.
+
+
+@node ctime
+@section ctime
+@findex ctime
+
+The @code{ctime} function need not be reentrant, and consequently is
+not required to be thread safe.  Implementations of @code{ctime}
+typically write the time stamp into static buffer.  If two threads
+call @code{ctime} at roughly the same time, you might end up with the
+wrong date in one of the threads, or some undefined string.  There is
+a re-entrant interface @code{ctime_r}, that take a pre-allocated
+buffer and length of the buffer, and return @code{NULL} on errors.
+The input buffer should be at least 26 bytes in size.  The output
+string is locale-independent.  However, years can have more than 4
+digits if @code{time_t} is sufficiently wide, so the length of the
+required output buffer is not easy to determine.  Increasing the
+buffer size when @code{ctime_r} return @code{NULL} is not necessarily
+sufficient. The @code{NULL} return value could mean some other error
+condition, which will not go away by increasing the buffer size.
+
+A more flexible function is @code{strftime}.  However, note that it is
+locale dependent.
+
+
+@node inet_ntoa
+@section inet_ntoa
+@findex inet_ntoa
+
+The @code{inet_ntoa} function need not be reentrant, and consequently
+is not required to be thread safe.  Implementations of
+@code{inet_ntoa} typically write the time stamp into static buffer.
+If two threads call @code{inet_ntoa} at roughly the same time, you
+might end up with the wrong date in one of the threads, or some
+undefined string.  Further, @code{inet_ntoa} is specific for
+@acronym{IPv4} addresses.
+
+A protocol independent function is @code{inet_ntop}.
+
+
+@node Out of memory handling
+@section Out of memory handling
+
+@cindex Out of Memory handling
+@cindex Memory allocation failure
+The GSS API does not have a standard error code for the out of memory
+error condition.  Instead of adding a non-standard error code, this
+library has chosen to adopt a different strategy.  Out of memory
+handling happens in rare situations, but performing the out of memory
+error handling after almost all API function invocations pollute your
+source code and might make it harder to spot more serious problems.
+The strategy chosen improve code readability and robustness.
+
+@cindex Aborting execution
+For most applications, aborting the application with an error message
+when the out of memory situation occur is the best that can be wished
+for.  This is how the library behaves by default.
+
+@vindex xalloc_fail_func
+However, we realize that some applications may not want to have the
+GSS library abort execution in any situation.  The GSS library support
+a hook to let the application regain control and perform its own
+cleanups when an out of memory situation has occured.  The application
+can define a function (having a @code{void} prototype, i.e., no return
+value and no parameters) and set the library variable
+@code{xalloc_fail_func} to that function.  The variable should be
+declared as follows.
+
+@example
+extern void (*xalloc_fail_func) (void);
+@end example
+
+The GSS library will invoke this function if an out of memory error
+occurs.  Note that after this the GSS library is in an undefined
+state, so you must unload or restart the application to continue call
+GSS library functions.  The hook is only intended to allow the
+application to log the situation in a special way.  Of course, care
+must be taken to not allocate more memory, as that will likely also
+fail.
+
+
+@node Invoking gnulib-tool
+@chapter Invoking gnulib-tool
+
+@pindex gnulib-tool
+@cindex invoking @command{gnulib-tool}
+
+Run @samp{gnulib-tool --help}, and use the source.
+@command{gnulib-tool} is the way to import Gnulib modules.
+
+
+@node Copying This Manual
+@appendix Copying This Manual
+
+@menu
+* GNU Free Documentation License::  License for copying this manual.
+@end menu
+
+@include fdl.texi
+
+
+@node Index
+@unnumbered Index
+
+@printindex cp
+
+@bye
deleted file mode 100644
--- a/doc/xalloc.texi
+++ /dev/null
@@ -1,39 +0,0 @@
-@node Out of Memory handling
-@section Out of Memory handling
-
-@cindex Out of Memory handling
-@cindex Memory allocation failure
-The GSS API does not have a standard error code for the out of memory
-error condition.  Instead of adding a non-standard error code, this
-library has chosen to adopt a different strategy.  Out of memory
-handling happens in rare situations, but performing the out of memory
-error handling after almost all API function invocations pollute your
-source code and might make it harder to spot more serious problems.
-The strategy chosen improve code readability and robustness.
-
-@cindex Aborting execution
-For most applications, aborting the application with an error message
-when the out of memory situation occur is the best that can be wished
-for.  This is how the library behaves by default.
-
-@vindex xalloc_fail_func
-However, we realize that some applications may not want to have the
-GSS library abort execution in any situation.  The GSS library support
-a hook to let the application regain control and perform its own
-cleanups when an out of memory situation has occured.  The application
-can define a function (having a @code{void} prototype, i.e., no return
-value and no parameters) and set the library variable
-@code{xalloc_fail_func} to that function.  The variable should be
-declared as follows.
-
-@example
-extern void (*xalloc_fail_func) (void);
-@end example
-
-The GSS library will invoke this function if an out of memory error
-occurs.  Note that after this the GSS library is in an undefined
-state, so you must unload or restart the application to continue call
-GSS library functions.  The hook is only intended to allow the
-application to log the situation in a special way.  Of course, care
-must be taken to not allocate more memory, as that will likely also
-fail.