Next: Introduction, Up: (dir) [Contents][Index]
| • Introduction: | ||
| • Configuration Files: | ||
| • The C API: | ||
| • The C++ API: | ||
| • Example Programs: | ||
| • Other Bindings and Implementations: | ||
| • License: | ||
| • Configuration File Grammar: | ||
| • Function Index: | ||
| • Type Index: | ||
| • Concept Index: |
Next: Configuration Files, Previous: Top, Up: Top [Contents][Index]
Libconfig is a library for reading, manipulating, and writing structured configuration files. The library features a fully reentrant parser and includes bindings for both the C and C++ programming languages.
The library runs on modern POSIX-compilant systems, such as Linux, Solaris, and Mac OS X (Darwin), as well as on Microsoft Windows 2000/XP and later (with either Microsoft Visual Studio 2005 or later, or the GNU toolchain via the MinGW environment).
Next: Using the Library from a C Program, Up: Introduction [Contents][Index]
There are several open-source configuration file libraries available as of this writing. This library was written because each of those libraries falls short in one or more ways. The main features of libconfig that set it apart from the other libraries are:
Next: Using the Library from a C++ Program, Previous: Why Another Configuration File Library?, Up: Introduction [Contents][Index]
To use the library from C code, include the following preprocessor directive in your source files:
#include <libconfig.h>
To link with the library, specify ‘-lconfig’ as an argument to the linker.
Next: Multithreading Issues, Previous: Using the Library from a C Program, Up: Introduction [Contents][Index]
To use the library from C++, include the following preprocessor directive in your source files:
#include <libconfig.h++>
Or, alternatively:
#include <libconfig.hh>
The C++ API classes are defined in the namespace ‘libconfig’, hence the following statement may optionally be used:
using namespace libconfig;
To link with the library, specify ‘-lconfig++’ as an argument to the linker.
Next: Internationalization Issues, Previous: Using the Library from a C++ Program, Up: Introduction [Contents][Index]
Libconfig is fully reentrant; the functions in the library do not make use of global variables and do not maintain state between successive calls. Therefore two independent configurations may be safely manipulated concurrently by two distinct threads.
Libconfig is not thread-safe. The library is not aware of the presence of threads and knows nothing about the host system’s threading model. Therefore, if an instance of a configuration is to be accessed from multiple threads, it must be suitably protected by synchronization mechanisms like read-write locks or mutexes; the standard rules for safe multithreaded access to shared data must be observed.
Libconfig is not async-safe. Calls should not be made into the library from signal handlers, because some of the C library routines that it uses may not be async-safe.
Libconfig is not guaranteed to be cancel-safe. Since it is not aware of the host system’s threading model, the library does not contain any thread cancellation points. In most cases this will not be an issue for multithreaded programs. However, be aware that some of the routines in the library (namely those that read/write configurations from/to files or streams) perform I/O using C library routines which may potentially block; whether or not these C library routines are cancel-safe depends on the host system.
Next: Compiling Using pkg-config, Previous: Multithreading Issues, Up: Introduction [Contents][Index]
Libconfig does not natively support Unicode configuration files, but string values may contain Unicode text encoded in UTF-8; such strings will be treated as ordinary 8-bit ASCII text by the library. It is the responsibility of the calling program to perform the necessary conversions to/from wide (wchar_t) strings using the wide string conversion functions such as mbsrtowcs() and wcsrtombs() or the iconv() function of the libiconv library.
The textual representation of a floating point value varies by locale. However, the libconfig grammar specifies that floating point values are represented using a period (‘.’) as the radix symbol; this is consistent with the grammar of most programming languages. When a configuration is read in or written out, libconfig temporarily changes the LC_NUMERIC category of the locale of the calling thread to the “C” locale to ensure consistent handling of floating point values regardless of the locale(s) in use by the calling program.
Note that the MinGW environment does not (as of this writing) provide functions for changing the locale of the calling thread. Therefore, when using libconfig in that environment, the calling program is responsible for changing the LC_NUMERIC category of the locale to the "C" locale before reading or writing a configuration.
Next: Version Test Macros, Previous: Internationalization Issues, Up: Introduction [Contents][Index]
On UNIX systems you can use the pkg-config utility (version 0.20
or later) to automatically select the appropriate compiler and linker
switches for libconfig. Ensure that the environment variable
PKG_CONFIG_PATH contains the absolute path to the
lib/pkgconfig subdirectory of the libconfig installation. Then,
you can compile and link C programs with libconfig as follows:
gcc `pkg-config --cflags libconfig` myprogram.c -o myprogram \
`pkg-config --libs libconfig`
And similarly, for C++ programs:
g++ `pkg-config --cflags libconfig++` myprogram.cpp -o myprogram \
`pkg-config --libs libconfig++`
Note the backticks in the above examples.
When using autoconf, the PKG_CHECK_MODULES m4 macro may be used to check for the presence of a given version of libconfig, and set the appropriate Makefile variables automatically. For example:
PKG_CHECK_MODULES([LIBCONFIGXX], [libconfig++ >= 1.4],, AC_MSG_ERROR([libconfig++ 1.4 or newer not found.]) )
In the above example, if libconfig++ version 1.4 or newer is found,
the Makefile variables LIBCONFIGXX_LIBS and LIBCONFIGXX_CFLAGS will be
set to the appropriate compiler and linker flags for compiling with
libconfig, and if it is not found, the configure script will abort
with an error to that effect.
Previous: Compiling Using pkg-config, Up: Introduction [Contents][Index]
The libconfig.h header declares the following macros:
These macros represent the major version, minor version, and revision of the libconfig library. For example, in libconfig 1.4 these are defined as ‘1’, ‘4’, and ‘0’, respectively. These macros can be used in preprocessor directives to determine which libconfig features and/or APIs are present. For example:
#if (((LIBCONFIG_VER_MAJOR == 1) && (LIBCONFIG_VER_MINOR >= 4)) \
|| (LIBCONFIG_VER_MAJOR > 1))
/* use features present in libconfig 1.4 and later */
#endif
These macros were introduced in libconfig 1.4.
Similarly, the libconfig.h++ header declares the following macros:
These macros represent the major version, minor version, and revision of the libconfig++ library.
Next: The C API, Previous: Introduction, Up: Top [Contents][Index]
| • Settings: | ||
| • Groups: | ||
| • Arrays: | ||
| • Lists: | ||
| • Integer Values: | ||
| • 64-bit Integer Values: | ||
| • Floating Point Values: | ||
| • Boolean Values: | ||
| • String Values: | ||
| • Comments: | ||
| • Include Directives: |
Libconfig supports structured, hierarchical configurations. These configurations can be read from and written to files and manipulated in memory.
A configuration consists of a group of settings, which associate names with values. A value can be one of the following:
Consider the following configuration file for a hypothetical GUI application, which illustrates all of the elements of the configuration file grammar.
# Example application configuration file
version = "1.0";
application:
{
window:
{
title = "My Application";
size = { w = 640; h = 480; };
pos = { x = 350; y = 250; };
};
list = ( ( "abc", 123, true ), 1.234, ( /* an empty list */ ) );
books = ( { title = "Treasure Island";
author = "Robert Louis Stevenson";
price = 29.95;
qty = 5; },
{ title = "Snow Crash";
author = "Neal Stephenson";
price = 9.99;
qty = 8; } );
misc:
{
pi = 3.141592654;
bigint = 9223372036854775807L;
columns = [ "Last Name", "First Name", "MI" ];
bitmask = 0x1FC3; // hex
umask = 0027; // octal. Range limited to that of "int"
};
};
|
Settings can be uniquely identified within the configuration by a path. The path is a dot-separated sequence of names, beginning at a top-level group and ending at the setting itself. Each name in the path is the name of a setting; if the setting has no name because it is an element in a list or array, an integer index in square brackets can be used as the name.
For example, in our hypothetical configuration file, the path to the
x setting is application.window.pos.x; the path to the
version setting is simply version; and the path to the
title setting of the second book in the books list is
application.books.[1].title.
The datatype of a value is determined from the format of the value
itself. If the value is enclosed in double quotes, it is treated as a
string. If it looks like an integer or floating point number, it is
treated as such. If it is one of the values TRUE, true,
FALSE, or false (or any other mixed-case version of
those tokens, e.g., True or FaLsE), it is treated as a
boolean. If it consists of a comma-separated list of values enclosed
in square brackets, it is treated as an array. And if it consists of a
comma-separated list of values enclosed in parentheses, it is treated
as a list. Any value which does not meet any of these criteria is
considered invalid and results in a parse error.
All names are case-sensitive. They may consist only of alphanumeric characters, dashes (‘-’), underscores (‘_’), and asterisks (‘*’), and must begin with a letter or asterisk. No other characters are allowed.
In C and C++, integer, 64-bit integer, floating point, and string
values are mapped to the native types int, long long,
double, and const char *, respectively. The boolean type
is mapped to int in C and bool in C++.
The following sections describe the elements of the configuration file grammar in additional detail.
Next: Groups, Up: Configuration Files [Contents][Index]
A setting has the form:
name = value ;
or:
name : value ;
The trailing semicolon is optional. Whitespace is not significant.
The value may be a scalar value, an array, a group, or a list.
Next: Arrays, Previous: Settings, Up: Configuration Files [Contents][Index]
A group has the form:
{ settings ... }
Groups can contain any number of settings, but each setting must have a unique name within the group.
Next: Lists, Previous: Groups, Up: Configuration Files [Contents][Index]
An array has the form:
[ value, value ... ]
An array may have zero or more elements, but the elements must all be scalar values of the same type.
The last element in an array may be followed by a comma, which will be ignored.
Next: Integer Values, Previous: Arrays, Up: Configuration Files [Contents][Index]
A list has the form:
( value, value ... )
A list may have zero or more elements, each of which can be a scalar value, an array, a group, or another list.
The last element in a list may be followed by a comma, which will be ignored.
Next: 64-bit Integer Values, Previous: Lists, Up: Configuration Files [Contents][Index]
Integers can be represented in one of two ways: as a series of one or more decimal digits (‘0’ - ‘9’), with an optional leading sign character (‘+’ or ‘-’); or as a hexadecimal value consisting of the characters ‘0x’ followed by a series of one or more hexadecimal digits (‘0’ - ‘9’, ‘A’ - ‘F’, ‘a’ - ‘f’). Additionally, octal notation integers (that is, those having a leading zero with non-zero value) are also allowed.
Next: Floating Point Values, Previous: Integer Values, Up: Configuration Files [Contents][Index]
Long long (64-bit) integers are represented identically to integers, except that an ‘L’ character is appended to indicate a 64-bit value. For example, ‘0L’ indicates a 64-bit integer value 0. As of version 1.5 of the library, the trailing ‘L’ is optional; if the integer value exceeds the range of a 32-bit integer, it will automatically be interpreted as a 64-bit integer.
The integer and 64-bit integer setting types are interchangeable to the extent that a conversion between the corresponding native types would not result in an overflow or underflow. For example, a long long value can be written to a setting that has an integer type, if that value is within the range of an int. This rule applies to every API function or method that reads a value from or writes a value to a setting: if the type conversion would not result in an overflow or underflow, then the call will succeed, and otherwise it will fail. This behavior was not well-defined prior to version 1.7 of the library.
Next: Boolean Values, Previous: 64-bit Integer Values, Up: Configuration Files [Contents][Index]
Floating point values consist of a series of one or more digits, one decimal point, an optional leading sign character (‘+’ or ‘-’), and an optional exponent. An exponent consists of the letter ‘E’ or ‘e’, an optional sign character, and a series of one or more digits.
Next: String Values, Previous: Floating Point Values, Up: Configuration Files [Contents][Index]
Boolean values may have one of the following values: ‘true’, ‘false’, or any mixed-case variation thereof.
Next: Comments, Previous: Boolean Values, Up: Configuration Files [Contents][Index]
String values consist of arbitrary text delimited by double quotes. Literal double quotes can be escaped by preceding them with a backslash: ‘\"’. The escape sequences ‘\\’, ‘\f’, ‘\n’, ‘\r’, and ‘\t’ are also recognized, and have the usual meaning.
In addition, the ‘\x’ escape sequence is supported; this sequence must be followed by exactly two hexadecimal digits, which represent an 8-bit ASCII value. For example, ‘\xFF’ represents the character with ASCII code 0xFF.
No other escape sequences are currently supported.
Adjacent strings are automatically concatenated, as in C/C++ source code. This is useful for formatting very long strings as sequences of shorter strings. For example, the following constructs are equivalent:
"The quick brown fox jumped over the lazy dog."
"The quick brown fox" " jumped over the lazy dog."
"The quick" /* comment */ " brown fox " // another comment "jumped over the lazy dog."
Next: Include Directives, Previous: String Values, Up: Configuration Files [Contents][Index]
Three types of comments are allowed within a configuration:
As expected, comment delimiters appearing within quoted strings are treated as literal text.
Comments are ignored when the configuration is read in, so they are not treated as part of the configuration. Therefore if the configuration is written back out to a stream, any comments that were present in the original configuration will be lost.
Previous: Comments, Up: Configuration Files [Contents][Index]
A configuration file may “include” the contents of other files using an include directive. This directive has the effect of inlining the contents of the named file(s) at the point of inclusion.
An include directive must appear on its own line in the input. It has the form:
@include "path"
The interpretation of path depends on the currently registered include function. The default include function prepends the include directory, if any, to path, and then interprets the result as a single, literal file path. The application may supply its own include function which does variable substitution, wildcard expansion, or other transformations, returning a list of zero or more paths to files whose contents should be inlined at the point of inclusion.
Any backslashes or double quotes in the path must be escaped as ‘\\’ and ‘\"’, respectively.
For example, consider the following two configuration files:
# file: quote.cfg
quote = "Criticism may not be agreeable, but it is necessary."
" It fulfils the same function as pain in the human"
" body. It calls attention to an unhealthy state of"
" things.\n"
"\t--Winston Churchill";
|
# file: test.cfg
info: {
name = "Winston Churchill";
@include "quote.cfg"
country = "UK";
};
|
The resulting configuration will be equivalent to one in which the contents of the file ‘quote.cfg’ appeared at the point where the include directive is placed.
Include files may be nested to a maximum of 10 levels; exceeding this limit results in a parse error.
When the path argument to an @include directive is a relative
path, then it will be interpreted as being relative to the include
directory that has been been set by means of
config_set_include_dir(). If no include directory has been set,
then it will be taken as being relative to the program’s current
working directory.
Like comments, include directives are not part of the configuration file syntax. They are processed before the configuration itself is parsed. Therefore, they are not preserved when the configuration is written back out to a stream. There is presently no support for programmatically inserting include directives into a configuration.
Next: The C++ API, Previous: Configuration Files, Up: Top [Contents][Index]
This chapter describes the C library API. The type config_t represents a configuration, and the type config_setting_t represents a configuration setting.
The boolean values CONFIG_TRUE and CONFIG_FALSE are
macros defined as (1) and (0), respectively.
These functions initialize and destroy the configuration object config.
config_init() initializes the config_t structure pointed to by
config as a new, empty configuration.
config_destroy() destroys the configuration config,
deallocating all memory associated with the configuration, but does not
attempt to deallocate the config_t structure itself.
Since v1.7
This function clears the configuration config. All child settings of the root setting are recursively destroyed. All other attributes of the configuration are left unchanged.
This function reads and parses a configuration from the given
stream into the configuration object config. It returns
CONFIG_TRUE on success, or CONFIG_FALSE on failure; the
config_error_text(), config_error_file(),
config_error_line(), and config_error_type() functions,
described below, can be used to obtain information about the error.
This function reads and parses a configuration from the file named
filename into the configuration object config. It returns
CONFIG_TRUE on success, or CONFIG_FALSE on failure; the
config_error_text() and config_error_line() functions,
described below, can be used to obtain information about the error.
This function reads and parses a configuration from the string
str into the configuration object config. It returns
CONFIG_TRUE on success, or CONFIG_FALSE on failure; the
config_error_text() and config_error_line() functions,
described below, can be used to obtain information about the error.
This function writes the configuration config to the given stream.
This function writes the configuration config to the file named
filename. It returns CONFIG_TRUE on success, or
CONFIG_FALSE on failure.
These functions, which are implemented as macros, return the text,
filename, and line number of the parse error, if one occurred during a
call to config_read(), config_read_string(), or
config_read_file(). Storage for the strings returned by
config_error_text() and config_error_file() are managed
by the library and released automatically when the configuration is
destroyed; these strings must not be freed by the caller. If the error
occurred in text that was read from a string or stream,
config_error_file() will return NULL.
This function, which is implemented as a macro, returns the type of
error that occurred during the last call to one of the read or write
functions. The config_error_t type is an enumeration with the
following values: CONFIG_ERR_NONE, CONFIG_ERR_FILE_IO,
CONFIG_ERR_PARSE. These represent success, a file I/O error,
and a parsing error, respectively.
config_set_include_dir() specifies the include directory,
include_dir, relative to which the files specified in
‘@include’ directives will be located for the configuration
config. By default, there is no include directory, and all
include files are expected to be relative to the current working
directory. If include_dir is NULL, the default behavior
is reinstated.
For example, if the include directory is set to /usr/local/etc, the include directive ‘@include "configs/extra.cfg"’ would include the file /usr/local/etc/configs/extra.cfg.
config_get_include_dir() returns the current include directory for the
configuration config, or NULL if none is set.
Since v1.7
Specifies the include function func to use when processing
include directives. If func is NULL, the default include function,
config_default_include_func(), will be reinstated.
The type config_include_fn_t is a type alias for a function whose signature is:
The function receives the configuration config, the configuration’s current include directory include_dir, the argument to the include directive path; and a pointer at which to return an error message error.
On success, the function should return a NULL-terminated array
of paths. Any relative paths must be relative to the program’s current
working directory. The contents of these files will be inlined at the point
of inclusion, in the order that the paths appear in the
array. Both the array and its elements should be heap allocated; the
library will take ownership of and eventually free the strings in the
array and the array itself.
On failure, the function should return NULL and set *error to a
static error string which should be used as the parse error for the
configuration; the library does not take ownership of or free this string.
The default include function, config_default_include_func(),
simply returns a NULL-terminated array containing either a copy
of path if it’s an absolute path, or a concatenation of
include_dir and path if it’s a relative path.
Application-supplied include functions can perform custom tasks like wildcard expansion or variable substitution. For example, consider the include directive:
@include "configs/*.cfg" |
The include function would be invoked with the path ‘configs/*.cfg’ and could do wildcard expansion on that path, returning a list of paths to files with the file extension ‘.cfg’ in the subdirectory ‘configs’. Each of these files would then be inlined at the location of the include directive.
Tasks like wildcard expansion and variable substitution are non-trivial to implement and typically require platform-specific code. In the interests of keeping the library as compact and platform-independent as possible, implementations of such include functions are not included.
Since v1.6
These functions get and set the number of decimal digits to output after the radix character when writing the configuration to a file or stream.
Valid values for digits range from 0 (no decimals) to about 15 (implementation defined). This parameter has no effect on parsing.
The default float precision is 6.
These functions get and set the options for the configuration config. The options affect how configurations are read and written. The following options are defined:
CONFIG_OPTION_AUTOCONVERTTurning this option on enables number auto-conversion for the configuration. When this feature is enabled, an attempt to retrieve a floating point setting’s value into an integer (or vice versa), or store an integer to a floating point setting’s value (or vice versa) will cause the library to silently perform the necessary conversion (possibly leading to loss of data), rather than reporting failure. By default this option is turned off.
CONFIG_OPTION_SEMICOLON_SEPARATORSThis option controls whether a semicolon (‘;’) is output after each setting when the configuration is written to a file or stream. (The semicolon separators are optional in the configuration syntax.) By default this option is turned on.
CONFIG_OPTION_COLON_ASSIGNMENT_FOR_GROUPSThis option controls whether a colon (‘:’) is output between each group setting’s name and its value when the configuration is written to a file or stream. If the option is turned off, an equals sign (‘=’) is output instead. (These tokens are interchangeable in the configuration syntax.) By default this option is turned on.
CONFIG_OPTION_COLON_ASSIGNMENT_FOR_NON_GROUPSThis option controls whether a colon (‘:’) is output between each non-group setting’s name and its value when the configuration is written to a file or stream. If the option is turned off, an equals sign (‘=’) is output instead. (These tokens are interchangeable in the configuration syntax.) By default this option is turned off.
CONFIG_OPTION_OPEN_BRACE_ON_SEPARATE_LINEThis option controls whether an open brace (‘{’) will be written on its own line when the configuration is written to a file or stream. If the option is turned off, the brace will be written at the end of the previous line. By default this option is turned on.
CONFIG_OPTION_ALLOW_SCIENTIFIC_NOTATION(Since v1.7)
This option controls whether scientific notation may be used as appropriate
when writing floating point values (corresponding to printf()
‘%g’ format) or should never be used (corresponding to printf()
‘%f’ format). By default this option is turned off.
CONFIG_OPTION_FSYNC(Since v1.7.1)
This option controls whether the config_write_file() function performs
an fsync operation after writing the configuration and before closing the
file. By default this option is turned off.
CONFIG_OPTION_ALLOW_OVERRIDES(Since v1.7.3) This option controls whether duplicate settings override previous settings with the same name. If this option is turned off, duplicate settings are rejected. By default this option is turned off.
Since v1.7
These functions get and set the given option of the configuration
config. The option is enabled if flag is CONFIG_TRUE and
disabled if it is CONFIG_FALSE.
See config_set_options() above for the list of available options.
These functions get and set the CONFIG_OPTION_AUTO_CONVERT
option. They are obsoleted by the config_set_option() and
config_get_option() functions described above.
These functions, which are implemented as macros, get and set the
default external format for settings in the configuration
config. If a non-default format has not been set for a setting
with config_setting_set_format(), this configuration-wide
default format will be used instead when that setting is written to a
file or stream.
These functions, which are implemented as macros, get and set the tab width for the configuration config. The tab width affects the formatting of the configuration when it is written to a file or stream: each level of nesting is indented by width spaces, or by a single tab character if width is 0. The tab width has no effect on parsing.
Valid tab widths range from 0 to 15. The default tab width is 2.
These functions look up the value of the setting in the configuration
config specified by the path path. They store the value of
the setting at value and return CONFIG_TRUE on
success. If the setting was not found or if the type of the value did
not match the type requested, they leave the data pointed to by
value unmodified and return CONFIG_FALSE.
Storage for the string returned by config_lookup_string() is
managed by the library and released automatically when the setting is
destroyed or when the setting’s value is changed; the string must not
be freed by the caller.
This function locates the setting in the configuration config
specified by the path path. It returns a pointer to the
config_setting_t structure on success, or NULL if the
setting was not found.
This function locates a setting by a path path relative to
the setting setting. It returns a pointer to the
config_setting_t structure on success, or NULL if the
setting was not found.
These functions return the value of the given setting. If the
type of the setting does not match the type requested, a 0 or
NULL value is returned. Storage for the string returned by
config_setting_get_string() is managed by the library and
released automatically when the setting is destroyed or when the
setting’s value is changed; the string must not be freed by the
caller.
These functions set the value of the given setting to
value. On success, they return CONFIG_TRUE. If
the setting does not match the type of the value, they return
CONFIG_FALSE. config_setting_set_string() makes a copy
of the passed string value, so it may be subsequently freed or
modified by the caller without affecting the value of the setting.
These functions look up the value of the child setting named
name of the setting setting. They store the value at
value and return CONFIG_TRUE on success. If the setting
was not found or if the type of the value did not match the type
requested, they leave the data pointed to by value unmodified
and return CONFIG_FALSE.
Storage for the string returned by config_setting_lookup_string() is
managed by the library and released automatically when the setting is
destroyed or when the setting’s value is changed; the string must not
be freed by the caller.
These functions get and set the external format for the setting setting.
The format must be one of the constants
CONFIG_FORMAT_DEFAULT or CONFIG_FORMAT_HEX. All settings
support the CONFIG_FORMAT_DEFAULT format. The
CONFIG_FORMAT_HEX format specifies hexadecimal formatting for
integer values, and hence only applies to settings of type
CONFIG_TYPE_INT and CONFIG_TYPE_INT64. If format
is invalid for the given setting, it is ignored.
If a non-default format has not been set for the setting, config_setting_get_format() returns the default format for the configuration, as set by config_set_default_format().
config_setting_set_format() returns CONFIG_TRUE on
success and CONFIG_FALSE on failure.
This function fetches the child setting named name from the group
setting. It returns the requested setting on success, or
NULL if the setting was not found or if setting is not a
group.
This function fetches the element at the given index index in the
setting setting, which must be an array, list, or group. It returns the
requested setting on success, or NULL if index is out of
range or if setting is not an array, list, or group.
These functions return the value at the specified index index in the
setting setting. If the setting is not an array or list, or if
the type of the element does not match the type requested, or if
index is out of range, they return 0 or NULL. Storage for
the string returned by config_setting_get_string_elem() is
managed by the library and released automatically when the setting is
destroyed or when its value is changed; the string must not be freed
by the caller.
These functions set the value at the specified index index in the
setting setting to value. If index is negative, a
new element is added to the end of the array or list. On success,
these functions return a pointer to the setting representing the
element. If the setting is not an array or list, or if the setting is
an array and the type of the array does not match the type of the
value, or if index is out of range, they return
NULL. config_setting_set_string_elem() makes a copy of
the passed string value, so it may be subsequently freed or
modified by the caller without affecting the value of the setting.
This function adds a new child setting or element to the setting
parent, which must be a group, array, or list. If parent
is an array or list, the name parameter is ignored and may be
NULL.
The function returns the new setting on success, or NULL if
parent is not a group, array, or list; or if there is already a
child setting of parent named name; or if type is
invalid. If type is a scalar type, the new setting will have a
default value of 0, 0.0, false, or NULL, as appropriate.
This function removes and destroys the setting named name from the parent setting parent, which must be a group. Any child settings of the setting are recursively destroyed as well.
The name parameter can also specify a setting path relative to the provided parent. (In that case, the setting will be looked up and removed.)
The function returns CONFIG_TRUE on success. If parent is
not a group, or if it has no setting with the given name, it returns
CONFIG_FALSE.
This function removes the child setting at the given index index from the setting parent, which must be a group, list, or array. Any child settings of the removed setting are recursively destroyed as well.
The function returns CONFIG_TRUE on success. If parent is
not a group, list, or array, or if index is out of range, it returns
CONFIG_FALSE.
This function, which is implemented as a macro, returns the root setting for the configuration config. The root setting is a group.
This function returns the name of the given setting, or
NULL if the setting has no name. Storage for the returned
string is managed by the library and released automatically when the
setting is destroyed; the string must not be freed by the caller.
This function returns the parent setting of the given setting,
or NULL if setting is the root setting.
This function returns CONFIG_TRUE if the given setting is
the root setting, and CONFIG_FALSE otherwise.
This function returns the index of the given setting within its parent setting. If setting is the root setting, this function returns -1.
This function returns the number of settings in a group, or the number of elements in a list or array. For other types of settings, it returns 0.
This function returns the type of the given setting. The return
value is one of the constants
CONFIG_TYPE_INT, CONFIG_TYPE_INT64, CONFIG_TYPE_FLOAT,
CONFIG_TYPE_STRING, CONFIG_TYPE_BOOL,
CONFIG_TYPE_ARRAY, CONFIG_TYPE_LIST, or CONFIG_TYPE_GROUP.
These convenience functions, which are implemented as macros, test if
the setting setting is of a given type. They return
CONFIG_TRUE or CONFIG_FALSE.
These convenience functions, some of which are implemented as macros, test if
the setting setting is of an aggregate type (a group, array, or
list), of a scalar type (integer, 64-bit integer, floating point,
boolean, or string), and of a number (integer, 64-bit integer, or
floating point), respectively. They return CONFIG_TRUE or
CONFIG_FALSE.
This function returns the name of the file from which the setting setting was read, or NULL if the setting was not read from a file. This information is useful for reporting application-level errors. Storage for the returned string is managed by the library and released automatically when the configuration is destroyed; the string must not be freed by the caller.
This function returns the line number of the configuration file or stream at which the setting setting was read, or 0 if no line number is available. This information is useful for reporting application-level errors.
Since v1.7
These functions make it possible to attach arbitrary data to a configuration structure, for instance a “wrapper” or “peer” object written in another programming language.
These functions make it possible to attach arbitrary data to each
setting structure, for instance a “wrapper” or “peer” object written in
another programming language. The destructor function, if one has been
supplied via a call to config_set_destructor(), will be called
by the library to dispose of this data when the setting itself is
destroyed. There is no default destructor.
This function assigns the destructor function destructor for the
configuration config. This function accepts a single void
* argument and has no return value. See
config_setting_set_hook() above for more information.
Next: Example Programs, Previous: The C API, Up: Top [Contents][Index]
This chapter describes the C++ library API. The class Config
represents a configuration, and the class Setting represents a
configuration setting. Note that by design, neither of these classes
provides a public copy constructor or assignment operator. Therefore,
instances of these classes may only be passed between functions via
references or pointers.
The library defines a group of exceptions, all of which extend the
common base exception ConfigException.
A SettingTypeException is thrown when the type of a setting’s
value does not match the type requested.
These methods construct SettingTypeException objects for the given setting and/or member index or name.
A SettingNotFoundException is thrown when a setting is not found.
These methods construct SettingTypeException objects for the given setting and member index or name, or path path.
A SettingNameException is thrown when an attempt is made to add
a new setting with a non-unique or invalid name.
This method constructs a SettingNameExcpetion object for the given setting and member name name.
A ParseException is thrown when a parse error occurs while
reading a configuration from a stream.
This method constructs a ParseException object with the given filename file, line number line, and error message error.
A FileIOException is thrown when an I/O error occurs while
reading/writing a configuration from/to a file.
SettingTypeException, SettingNotFoundException, and
SettingNameException all extend the common base
exception SettingException, which provides the following method:
This method returns the path to the setting associated with the exception, or
NULL if there is no applicable path.
The remainder of this chapter describes the methods for manipulating configurations and configuration settings.
These methods create and destroy Config objects.
Since v1.7
This method clears the configuration. All child settings of the root setting are recursively destroyed. All other attributes of the configuration are left unchanged.
The read() method reads and parses a configuration from the given
stream. A ParseException is thrown if a parse error occurs.
The write() method writes the configuration to the given stream.
The readFile() method reads and parses a configuration from the
file named filename. A ParseException is thrown if a
parse error occurs. A FileIOException is thrown if the file
cannot be read.
The writeFile() method writes the configuration to the file
named filename. A FileIOException is thrown if the file cannot
be written.
These methods read and parse a configuration from the string
str. A ParseException is thrown if a parse error occurs.
If a call to readFile(), readString(), or read()
resulted in a ParseException, these methods can be called on
the exception object to obtain the text, filename, and line number of
the parse error. Storage for the strings returned by getError()
and getFile() are managed by the library; the strings must not
be freed by the caller.
The setIncludeDir() method specifies the include directory,
includeDir, relative to which the files specified in
‘@include’ directives will be located for the configuration. By
default, there is no include directory, and all include files are
expected to be relative to the current working directory. If
includeDir is NULL, the default behavior is reinstated.
For example, if the include directory is set to /usr/local/etc, the include directive ‘@include "configs/extra.cfg"’ would include the file /usr/local/etc/configs/extra.cfg.
getIncludeDir() returns the current include directory for the
configuration, or NULL if none is set.
Since v1.7
This method is called to evaluate the path of an @include directive.
The path is the literal path argument of the directive. The method may
be overridden in a subclass to perform tasks like wildcard expansion and
variable substitution.
On success, the method should return a NULL-terminated array of paths.
Any relative paths must be relative to the program’s current working directory.
The contents of these files will be inlined at the point of inclusion, in the
order that the paths appear in the array. Both the array and its elements should
be heap allocated; the library will take ownership of and eventually free the
strings in the array and the array itself.
On failure, the function should return NULL and set *error to a
static error string which should be used as the parse error for the
configuration; the library does not take ownership of or free this string.
The default implementation simply returns a NULL-terminated array
containing either a copy of path if it’s an absolute path, or a
concatenation of the include directory and path if it’s a relative path.
For more information see config_set_include_func() above.
These methods get and set the options for the configuration. The options affect how configurations are read and written. The parameter options should be a bitwise-OR of the following Config::Option enumeration values:
Config::OptionAutoConvertTurning this option on enables number auto-conversion for the configuration. When this feature is enabled, an attempt to retrieve a floating point setting’s value into an integer (or vice versa), or store an integer to a floating point setting’s value (or vice versa) will cause the library to silently perform the necessary conversion (possibly leading to loss of data), rather than reporting failure. By default this option is turned off.
Config::OptionSemicolonSeparatorsThis option controls whether a semicolon (‘;’) is output after each setting when the configuration is written to a file or stream. (The semicolon separators are optional in the configuration syntax.) By default this option is turned on.
Config::OptionColonAssignmentForGroupsThis option controls whether a colon (‘:’) is output between each group setting’s name and its value when the configuration is written to a file or stream. If the option is turned off, an equals sign (‘=’) is output instead. (These tokens are interchangeable in the configuration syntax.) By default this option is turned on.
Config::OptionColonAssignmentForNonGroupsThis option controls whether a colon (‘:’) is output between each non-group setting’s name and its value when the configuration is written to a file or stream. If the option is turned off, an equals sign (‘=’) is output instead. (These tokens are interchangeable in the configuration syntax.) By default this option is turned off.
Config::OptionOpenBraceOnSeparateLineThis option controls whether an open brace (‘{’) will be written on its own line when the configuration is written to a file or stream. If the option is turned off, the brace will be written at the end of the previous line. By default this option is turned on.
Config::OptionAllowScientificNotation(Since v1.7)
This option controls whether scientific notation may be used as appropriate
when writing floating point values (corresponding to printf()
‘%g’ format) or should never be used (corresponding to printf()
‘%f’ format). By default this option is turned off.
Config::OptionFsync(Since v1.7.1)
This option controls whether the writeFile() method performs an fsync
operation after writing the configuration and before closing the file. By
default this option is turned off.
Config::OptionAllowOverrides(Since v1.7.3) This option controls whether duplicate settings override previous settings with the same name. If this option is turned off, duplicate settings are rejected. By default this option is turned off.
Since v1.7
These methods get and set the option option for the configuration. The
option is enabled if flag is true and disabled if it is
false.
See setOptions() above for the list of available options.
These methods get and set the OptionAutoConvert option. They
are obsoleted by the setOption() and getOption()
methods described above.
These methods get and set the default external format for settings in
the configuration. If a non-default format has not been set for a
setting with Setting::setFormat(), this configuration-wide
default format will be used instead when that setting is written to a
file or stream.
These methods get and set the tab width for the configuration. The tab width affects the formatting of the configuration when it is written to a file or stream: each level of nesting is indented by width spaces, or by a single tab character if width is 0. The tab width has no effect on parsing.
Valid tab widths range from 0 to 15. The default tab width is 2.
These methods get and set the float precision for the configuration. This parameter influences the formatting of floating point settings in the configuration when it is written to a file or stream. Float precision has no effect on parsing.
Valid precisions range from 0 to about 15 (implementation dependent), though the library will accept and store values up to 255.
This method returns the root setting for the configuration, which is a group.
These methods locate the setting specified by the path path. If
the requested setting is not found, a SettingNotFoundException is
thrown.
These methods test if a setting with the given path exists in
the configuration. They return true if the setting exists, and
false otherwise. These methods do not throw exceptions.
These are convenience methods for looking up the value of a setting
with the given path. If the setting is found and is of an
appropriate type, the value is stored in value and the method
returns true. Otherwise, value is left unmodified and the
method returns false. These methods do not throw exceptions.
Storage for const char * values is managed by the library and
released automatically when the setting is destroyed or when its value
is changed; the string must not be freed by the caller. For safety and
convenience, always assigning string values to a std::string is
suggested.
Since these methods have boolean return values and do not throw exceptions, they can be used within boolean logic expressions. The following example presents a concise way to look up three values at once and perform error handling if any of them are not found or are of the wrong type:
int var1;
double var2;
const char *var3;
if(config.lookupValue("values.var1", var1)
&& config.lookupValue("values.var2", var2)
&& config.lookupValue("values.var3", var3))
{
// use var1, var2, var3
}
else
{
// error handling here
}
|
This approach also takes advantage of the short-circuit evaluation rules
of C++, e.g., if the first lookup fails (returning false), the
remaining lookups are skipped entirely.
These cast operators allow a Setting object to be assigned to a
variable of type bool if it is of type TypeBoolean;
int, unsigned int; long long or unsigned long long if
it is of type TypeInt64, float or double if it is of type
TypeFloat; or const char * or std::string if it is
of type TypeString.
Values of type TypeInt or TypeInt64 may be assigned to
variables of type long, or unsigned long, depending on the
sizes of those types on the host system.
Storage for const char * return values is managed by the
library and released automatically when the setting is destroyed or
when its value is changed; the string must not be freed by the
caller. For safety and convenience, always assigning string return
values to a std::string is suggested.
The following examples demonstrate this usage:
long width = config.lookup("application.window.size.w");
bool splashScreen = config.lookup("application.splash_screen");
std::string title = config.lookup("application.window.title");
|
Note that certain conversions can lead to loss of precision or clipping of values, e.g., assigning a negative value to an unsigned int (in which case the value will be treated as 0), or a double-precision value to a float. The library does not treat these lossy conversions as errors.
Perhaps surprisingly, the following code in particular will cause a compiler error:
std::string title;
.
.
.
title = config.lookup("application.window.title");
|
This is because the assignment operator of std::string is being
invoked with a Setting & as an argument. The compiler is unable
to make an implicit conversion because both the const char *
and the std::string cast operators of Setting are
equally appropriate. This is not a bug in libconfig; providing
only the const char * cast operator would resolve this
particular ambiguity, but would cause assignments to
std::string like the one in the previous example to produce a
compiler error. (To understand why, see section 11.4.1 of The C++
Programming Language.)
The solution to this problem is to use an explicit conversion that
avoids the construction of an intermediate std::string object,
as follows:
std::string title;
.
.
.
title = (const char *)config.lookup("application.window.title");
|
Or, alternatively, use the c_str() method, which has the same effect:
std::string title;
.
.
.
title = config.lookup("application.window.title").c_str();
|
If the assignment is invalid due to a type mismatch, a
SettingTypeException is thrown.
These assignment operators allow values of type bool, int, long, long long, float, double, const char *, and std::string to be assigned to a setting. In the case of strings, the library makes a copy of the passed string value, so it may be subsequently freed or modified by the caller without affecting the value of the setting.
The following example code looks up a (presumably) integer setting and changes its value:
Setting &setting = config.lookup("application.window.size.w");
setting = 1024;
|
If the assignment is invalid due to a type mismatch, a
SettingTypeException is thrown.
A Setting object may be subscripted with an integer index
index if it is an array or list, or with either a string
name or an integer index index if it is a group. For example,
the following code would produce the string ‘Last Name’ when
applied to the example configuration in Configuration Files.
Setting& setting = config.lookup("application.misc");
const char *s = setting["columns"][0];
|
If the setting is not an array, list, or group, a
SettingTypeException is thrown. If the subscript (index
or name) does not refer to a valid element, a
SettingNotFoundException is thrown.
Iterating over a group’s child settings with an integer index will return the settings in the same order that they appear in the configuration.
These methods locate a setting by a path path relative to
this setting. If requested setting is not found, a
SettingNotFoundException is thrown.
These are convenience methods for looking up the value of a child setting
with the given name. If the setting is found and is of an
appropriate type, the value is stored in value and the method
returns true. Otherwise, value is left unmodified and the
method returns false. These methods do not throw exceptions.
Storage for const char * values is managed by the library and
released automatically when the setting is destroyed or when its value
is changed; the string must not be freed by the caller. For safety and
convenience, always assigning string values to a std::string is
suggested.
Since these methods have boolean return values and do not throw exceptions, they can be used within boolean logic expressions. The following example presents a concise way to look up three values at once and perform error handling if any of them are not found or are of the wrong type:
int var1;
double var2;
const char *var3;
if(setting.lookupValue("var1", var1)
&& setting.lookupValue("var2", var2)
&& setting.lookupValue("var3", var3))
{
// use var1, var2, var3
}
else
{
// error handling here
}
|
This approach also takes advantage of the short-circuit evaluation
rules of C++, e.g., if the first lookup fails (returning false), the
remaining lookups are skipped entirely.
These methods add a new child setting with the given name and
type to the setting, which must be a group. They return a
reference to the new setting. If the setting already has a child
setting with the given name, or if the name is invalid, a
SettingNameException is thrown. If the setting is not a group,
a SettingTypeException is thrown.
Once a setting has been created, neither its name nor type can be changed.
This method adds a new element to the setting, which must be of type
TypeArray or TypeList. If the setting is an array which
currently has zero elements, the type parameter (which must be
TypeInt, TypeInt64, TypeFloat, TypeBool,
or TypeString) determines the type for the array; otherwise it
must match the type of the existing elements in the array.
The method returns the new setting on success. If type is a
scalar type, the new setting will have a default value of 0, 0.0,
false, or NULL, as appropriate.
The method throws a SettingTypeException if the setting is not
an array or list, or if type is invalid.
These methods remove the child setting with the given name from the setting, which must be a group. Any child settings of the removed setting are recursively destroyed as well.
If the setting is not a group, a SettingTypeException is
thrown. If the setting does not have a child setting with the given
name, a SettingNotFoundException is thrown.
This method removes the child setting at the given index index from the setting, which must be a group, list, or array. Any child settings of the removed setting are recursively destroyed as well.
If the setting is not a group, list, or array, a
SettingTypeException is thrown. If index is out of range,
a SettingNotFoundException is thrown.
This method returns the name of the setting, or NULL if the
setting has no name. Storage for the returned string is managed by the
library and released automatically when the setting is destroyed; the
string must not be freed by the caller. For safety and convenience,
consider assigning the return value to a std::string.
This method returns the complete dot-separated path to the setting. Settings which do not have a name (list and array elements) are represented by their index in square brackets.
This method returns the parent setting of the setting. If the setting
is the root setting, a SettingNotFoundException is thrown.
This method returns true if the setting is the root setting, and
false otherwise.
This method returns the index of the setting within its parent setting. When applied to the root setting, this method returns -1.
This method returns the type of the setting. The
Setting::Type enumeration consists of the following constants:
TypeInt, TypeInt64, TypeFloat, TypeString,
TypeBoolean, TypeArray, TypeList, and
TypeGroup.
These methods get and set the external format for the setting.
The Setting::Format enumeration consists of the following
constants: FormatDefault and FormatHex. All settings
support the FormatDefault format. The FormatHex format
specifies hexadecimal formatting for integer values, and hence only
applies to settings of type TypeInt and TypeInt64. If
format is invalid for the given setting, it is ignored.
These methods test if the setting has a child setting with the given
name. They return true if the setting exists, and
false otherwise. These methods do not throw exceptions.
These methods return STL-style iterators that can be used to enumerate
the child settings of a given setting. If the setting is not an array, list,
or group, they throw a SettingTypeException.
This method returns the number of settings in a group, or the number of elements in a list or array. For other types of settings, it returns 0.
These convenience methods test if a setting is of a given type.
These convenience methods test if a setting is of an aggregate type (a group, array, or list), of a scalar type (integer, 64-bit integer, floating point, boolean, or string), of a number (integer, 64-bit integer, or floating point), and of a string respectively.
This method returns the name of the file from which the setting was read, or NULL if the setting was not read from a file. This information is useful for reporting application-level errors. Storage for the returned string is managed by the library and released automatically when the configuration is destroyed; the string must not be freed by the caller.
This method returns the line number of the configuration file or stream at which the setting setting was read, or 0 if no line number is available. This information is useful for reporting application-level errors.
Next: Other Bindings and Implementations, Previous: The C++ API, Up: Top [Contents][Index]
Practical example programs that illustrate how to use libconfig from both C and C++ are included in the examples subdirectory of the distribution. These examples include:
An example C program that reads a configuration from an existing file example.cfg (also located in examples/c) and displays some of its contents.
The C++ equivalent of example1.c.
An example C program that reads a configuration from an existing file example.cfg (also located in examples/c), adds new settings to the configuration, and writes the updated configuration to another file.
The C++ equivalent of example2.c
An example C program that constructs a new configuration in memory and writes it to a file.
The C++ equivalent of example3.c
An example C program that uses a custom include function for processing wildcard includes. Note that this code will not compile on Windows.
Next: License, Previous: Example Programs, Up: Top [Contents][Index]
| • Bourne Shell: | ||
| • D: | ||
| • Haskell: | ||
| • Java: | ||
| • Lisp: | ||
| • Perl: | ||
| • Python: | ||
| • Ruby: |
Various open-source libraries have been written that provide access to libconfig-style configuration files from other programming languages. Some of these libraries are wrappers which add new language bindings for libconfig while others are syntax-compatible reimplementations in other languages.
Here is a list of some of these implementations.
Next: D, Up: Other Bindings and Implementations [Contents][Index]
Łukasz A. Grabowski’s ls-config provides a means to read and write values in libconfig configuration files from Bourne shell scripts. The implementation is included in the libconfig git repository at https://github.com/hyperrealm/libconfig, in the contrib/ls-config subdirectory.
Next: Haskell, Previous: Bourne Shell, Up: Other Bindings and Implementations [Contents][Index]
Remi Thebault’s libconfig-d is a port of libconfig to the D programming language. It may be found at https://code.dlang.org/packages/libconfig-d.
Next: Java, Previous: D, Up: Other Bindings and Implementations [Contents][Index]
Matthew Peddie’s libconfig provides Haskell bindings to libconfig. It may be found at https://hackage.haskell.org/package/libconfig-0.3.0.0.
Next: Lisp, Previous: Haskell, Up: Other Bindings and Implementations [Contents][Index]
Andrey V. Pleskach has a pure-Java implementation of libconfig. It may be found on github at https://github.com/willyborankin/libconfig.
Next: Perl, Previous: Java, Up: Other Bindings and Implementations [Contents][Index]
Oleg Shalaev’s cl-libconfig provides Common Lisp bindings for libconfig. It may be found on github at https://github.com/chalaev/cl-libconfig.
Next: Python, Previous: Lisp, Up: Other Bindings and Implementations [Contents][Index]
The Conf::Libconfig module provides Perl bindings for libconfig. It may be found on CPAN at http://search.cpan.org/~cnangel/Conf-Libconfig-0.05/ or on github at https://github.com/cnangel/Conf-Libconfig.
Next: Ruby, Previous: Perl, Up: Other Bindings and Implementations [Contents][Index]
Heiner Tholen’s pylibconfig2 is a Python library that is syntax-compatible with libconfig. It may be found at https://pypi.python.org/pypi/pylibconfig2/0.1.2.
Christian Aichinger’s libconf is another pure-Python implementation with a more permissive license. It may be found at https://pypi.python.org/pypi/libconf or on github at https://github.com/Grk0/python-libconf.
The python-libconfig wrapper provides Python bindings to libconfig. It may be found on github at https://github.com/cnangel/python-libconfig/.
Previous: Python, Up: Other Bindings and Implementations [Contents][Index]
Christopher Mark Gore’s ruby-libconfig is a Ruby library that provides Ruby bindings for libconfig. It may be found at https://rubygems.org/gems/libconfig or on github at https://github.com/cgore/ruby-libconfig.
There is also another Ruby wrapper, libconfig-ruby, that is included in the libconfig git repository at https://github.com/hyperrealm/libconfig, in the contrib/libconfig-ruby subdirectory.
Next: Configuration File Grammar, Previous: Other Bindings and Implementations, Up: Top [Contents][Index]
Copyright © 1991, 1999 Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
[This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.]
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software–to make sure the software is free for all its users.
This license, the Lesser General Public License, applies to some specially designated software packages–typically libraries–of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below.
When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things.
To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it.
For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights.
We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library.
To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author’s reputation will not be affected by problems that might be introduced by others.
Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license.
Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs.
When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.
We call this license the “Lesser” General Public License because it does Less to protect the user’s freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances.
For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License.
In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system.
Although the Lesser General Public License is Less protective of the users’ freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library.
The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a “work based on the library” and a “work that uses the library”. The former contains code derived from the library, whereas the latter must be combined with the library in order to run.
A “library” means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables.
The “Library”, below, refers to any such software library or work which has been distributed under these terms. A “work based on the Library” means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term “modification”.)
“Source code” for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library.
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
(For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library.
In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.
This option is useful when you wish to copy part of the code of the Library into a program that is not a library.
If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code.
However, linking a “work that uses the Library” with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a “work that uses the library”. The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.
When a “work that uses the Library” uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself.
You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:
For an executable, the required form of the “work that uses the Library” must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and “any later version”, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation.
If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License).
To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.
<one line to give the library's name and a brief idea of what it does.> Copyright (C) <year> <name of author> This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Also add information on how to contact you by electronic and paper mail.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a “copyright disclaimer” for the library, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker. <signature of Ty Coon>, 1 April 1990 Ty Coon, President of Vice
That’s all there is to it!
Next: Function Index, Previous: License, Up: Top [Contents][Index]
Below is the BNF grammar for configuration files. Comments and include directives are not part of the grammar, so they are not included here.
<configuration> ::=
<setting-list>
| <empty>
<setting-list> ::=
<setting>
| <setting-list> <setting>
<setting> ::=
<name> ( ":" | "=" ) <value> ( ";" | "," | <empty> )
<value> ::=
<scalar-value>
| <array>
| <list>
| <group>
<value-list> ::=
<value>
| <value-list> "," <value>
| <value-list> ","
<scalar-value> ::=
<boolean>
| <integer>
| <integer64>
| <hex>
| <hex64>
| <float>
| <string>
<scalar-value-list> ::=
<scalar-value>
| <scalar-value-list> "," <scalar-value>
| <scalar-value-list> ","
<array> ::=
"[" ( <scalar-value-list> | <empty> ) "]"
<list> ::=
"(" ( <value-list> | <empty> ) ")"
<group> ::=
"{" ( <setting-list> | <empty> ) "}"
<empty> ::=
Terminals are defined below as regular expressions:
<boolean> | ([Tt][Rr][Uu][Ee])|([Ff][Aa][Ll][Ss][Ee]) |
<string> | \"([^\"\\]|\\.)*\" |
<name> | [A-Za-z\*][-A-Za-z0-9_\*]* |
<integer> | [-+]?[0-9]+ |
<integer64> | [-+]?[0-9]+L(L)? |
<hex> | 0[Xx][0-9A-Fa-f]+ |
<hex64> | 0[Xx][0-9A-Fa-f]+(L(L)?)? |
<float> | ([-+]?([0-9]*)?\.[0-9]*([eE][-+]?[0-9]+)?)|([-+]([0-9]+)(\.[0-9]*)?[eE][-+]?[0-9]+) |
Note that adjacent strings are automatically concatenated. Non-printable characters can be represented within strings using a sequence ‘\xx’, representing the ASCII value as two hex digits.
Next: Type Index, Previous: Configuration File Grammar, Up: Top [Contents][Index]
| Jump to: | ~
A B C E F G I L O P R S W |
|---|
| Jump to: | ~
A B C E F G I L O P R S W |
|---|
Next: Concept Index, Previous: Function Index, Up: Top [Contents][Index]
| Jump to: | C F P S |
|---|
| Jump to: | C F P S |
|---|
Previous: Type Index, Up: Top [Contents][Index]
| Jump to: | A C D E F G H I L P S U V |
|---|
| Jump to: | A C D E F G H I L P S U V |
|---|