which is a library of common routines intended to be shared at the
source level.
-Copyright @copyright{} 2004-2010 Free Software Foundation, Inc.
+Copyright @copyright{} 2004-2011 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
@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 improves code readability and robustness.
+The gnulib API does not have a standard error code for the out of memory
+error condition. Instead of adding a non-standard error code, gnulib
+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 improves code readability and robustness.
@cindex Aborting execution
For most applications, aborting the application with an error message
when the out of memory situation occurs 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 supports
-a hook to let the application regain control and perform its own
-cleanups when an out of memory situation has occurred. 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
+for. This is how the library behaves by default (using
+the @samp{xalloc-die} module).
+
+@vindex xalloc_die
+However, we realize that some applications may not want to abort
+execution in any situation. Gnulib supports a hook to let the
+application regain control and perform its own cleanups when an out of
+memory situation has occurred. 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_die} to that function. The variable should be
declared as follows.
@example
-extern void (*xalloc_fail_func) (void);
+extern void (*xalloc_die) (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.
+Gnulib will invoke this function if an out of memory error occurs. Note
+that the function should not return. Of course, care must be taken to
+not allocate more memory, as that will likely also fail.
@node Obsolete modules
Windows 2000 does not have getaddrinfo in its @file{WS2_32.DLL}.
Thus, if you want to assume Windows XP or later, you can add
-AC_DEFINE(WINVER, 0x0501) to avoid compiling to (partial) getaddrinfo
+AC_DEFINE(WINVER, 0x0501) to avoid compiling the (partial) getaddrinfo
implementation.
If you want to support Windows 2000, don't do anything. The
* Visual Studio Compatibility::
* Supporting Relocation::
* func::
+* configmake::
* warnings::
* manywarnings::
* Running self-tests under valgrind::
@include func.texi
+@include configmake.texi
+
@include warnings.texi
@include manywarnings.texi