@comment %**start of header
@setfilename gnulib.info
@settitle GNU Gnulib
+@c Define a new index for the magic constants in regex.texi.
+@defcodeindex cn
@syncodeindex fn cp
+@syncodeindex ky cp
@syncodeindex pg cp
+@syncodeindex tp cp
+@syncodeindex vr cp
+@syncodeindex cn cp
@ifclear texi2html
@firstparagraphindent insert
@end ifclear
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
* Glibc Header File Substitutes:: Overriding system headers.
* Glibc Function Substitutes:: Replacing system functions.
* Particular Modules:: Documentation of individual modules.
+* Regular expressions:: The regex module.
* GNU Free Documentation License:: Copying and sharing this manual.
* Index::
@end menu
* Benefits::
* Library vs Reusable Code::
* Portability and Application Code::
+* Target Platforms::
* Modules::
* Various Kinds of Modules::
* Collaborative Development::
depend on tests modules. (Recall that tests modules are built in a separate
directory.)
+Each listed required module may be declared a conditional dependency. This
+is indicated by placing the condition for the dependency on the same line,
+enclosed in brackets, after the name of the required module. The condition
+is a shell expression that is run after the module's @code{configure.ac}
+statements. For example:
+@smallexample
+strtoull [test $ac_cv_func_strtoumax = no]
+@end smallexample
+
@item configure.ac-early
This field contains @file{configure.ac} stuff (Autoconf macro invocations and
shell statements) that are logically placed early in the @file{configure.ac}
The body of the test, then, contains many @code{ASSERT} invocations. When
a test fails, the @code{ASSERT} macro prints the line number of the failing
-statement, thus giving you as a developer a idea which part of the test
+statement, thus giving you, the developer, an idea of which part of the test
failed, even when you don't have access to the machine where the test failed
and the reporting user cannot run a debugger.
@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
* alloca::
* alloca-opt::
* Safe Allocation Macros::
+* Compile-time Assertions::
+* Integer Properties::
* String Functions in C Locale::
* Quoting::
* error and progname::
* gcd::
-* Regular expressions::
* Searching for Libraries::
* Exported Symbols of Shared Libraries::
* LD Version Scripts::
* Visual Studio Compatibility::
* Supporting Relocation::
* func::
+* configmake::
* warnings::
* manywarnings::
* Running self-tests under valgrind::
@include safe-alloc.texi
+@include verify.texi
+
+@include intprops.texi
+
@node String Functions in C Locale
@section Character and String Functions in C Locale
@include gcd.texi
-@node Regular expressions
-@section Regular expressions
-
-Gnulib supports many different types of regular expressions; although
-the underlying features are the same or identical, the syntax used
-varies. The descriptions given here for the different types are
-generated automatically.
-
-@include regexprops-generic.texi
-
@include havelib.texi
@include lib-symbol-visibility.texi
@include func.texi
+@include configmake.texi
+
@include warnings.texi
@include manywarnings.texi
@include valgrind-tests.texi
+@node Regular expressions
+@chapter Regular expressions
+
+@menu
+* Overview::
+* Regular Expression Syntax::
+* Common Operators::
+* GNU Operators::
+* GNU Emacs Operators::
+* What Gets Matched?::
+* Programming with Regex::
+* Regular expression syntaxes::
+@end menu
+
+@lowersections
+@include regex.texi
+@raisesections
+
+@node Regular expression syntaxes
+@section Regular expression syntaxes
+
+Gnulib supports many different types of regular expressions; although
+the underlying features are the same or identical, the syntax used
+varies. The descriptions given here for the different types are
+generated automatically.
+
+@include regexprops-generic.texi
+
@node GNU Free Documentation License
@appendix GNU Free Documentation License
projects / gnulib.git / blobdiff