mirror of
git://sourceware.org/git/glibc.git
synced 2024-11-27 03:41:23 +08:00
Fix ChangeLog
This commit is contained in:
commit
77219e1b66
49
ChangeLog
49
ChangeLog
@ -7,6 +7,55 @@
|
||||
* posix/bug-regex33.c: New file.
|
||||
* posix/Makefile (tests): Add bug-regex33.
|
||||
|
||||
2012-02-28 Joseph Myers <joseph@codesourcery.com>
|
||||
|
||||
* manual/macros.texi: New file.
|
||||
* Makefile (INSTALL, NOTES): Depend on manual/macros.texi.
|
||||
* manual/libc.texinfo: Include macros.texi.
|
||||
* manual/creatute.texi: Likewise.
|
||||
* manual/install.texi: Likewise.
|
||||
* manual/arith.texi: Use macros @Theglibc{}, @theglibc{} and
|
||||
@glibcadj{} in references to the GNU C Library.
|
||||
* manual/charset.texi: Likewise.
|
||||
* manual/conf.texi: Likewise.
|
||||
* manual/contrib.texi: Likewise. Consistently use "GNU C Library"
|
||||
when not using those macros.
|
||||
* manual/creature.texi: Likewise.
|
||||
* manual/crypt.texi: Likewise.
|
||||
* manual/errno.texi: Likewise.
|
||||
* manual/filesys.texi: Likewise.
|
||||
* manual/header.texi: Likewise.
|
||||
* manual/install.texi: Likewise.
|
||||
* manual/intro.texi: Likewise.
|
||||
* manual/io.texi: Likewise.
|
||||
* manual/job.texi: Likewise.
|
||||
* manual/lang.texi: Likewise.
|
||||
* manual/libc.texiinfo: Likewise.
|
||||
* manual/llio.texi: Likewise.
|
||||
* manual/locale.texi: Likewise.
|
||||
* manual/maint.texi: Likewise.
|
||||
* manual/math.texi: Likewise.
|
||||
* manual/memory.texi: Likewise.
|
||||
* manual/message.texi: Likewise.
|
||||
* manual/nss.texi: Likewise.
|
||||
* manual/pattern.texi: Likewise.
|
||||
* manual/process.texi: Likewise.
|
||||
* manual/resource.texi: Likewise.
|
||||
* manual/search.texi: Likewise.
|
||||
* manual/setjmp.texi: Likewise.
|
||||
* manual/signal.texi: Likewise.
|
||||
* manual/socket.texi: Likewise.
|
||||
* manual/startup.texi: Likewise.
|
||||
* manual/stdio.texi: Likewise.
|
||||
* manual/string.texi: Likewise.
|
||||
* manual/sysinfo.texi: Likewise.
|
||||
* manual/syslog.texi: Likewise.
|
||||
* manual/terminal.texi: Likewise.
|
||||
* manual/time.texi: Likewise.
|
||||
* manual/users.texi: Likewise.
|
||||
* INSTALL: Regenerated.
|
||||
* NOTES: Regenerated.
|
||||
|
||||
2012-02-28 Andreas Schwab <schwab@linux-m68k.org>
|
||||
|
||||
* include/dirent.h: Include <dirstream.h> before
|
||||
|
188
INSTALL
188
INSTALL
@ -6,24 +6,24 @@ the top level of the source tree. This file answers common questions
|
||||
and describes problems you may experience with compilation and
|
||||
installation. It is updated more frequently than this manual.
|
||||
|
||||
Features can be added to GNU Libc via "add-on" bundles. These are
|
||||
separate tar files, which you unpack into the top level of the source
|
||||
tree. Then you give `configure' the `--enable-add-ons' option to
|
||||
activate them, and they will be compiled into the library.
|
||||
Features can be added to the GNU C Library via "add-on" bundles.
|
||||
These are separate tar files, which you unpack into the top level of
|
||||
the source tree. Then you give `configure' the `--enable-add-ons'
|
||||
option to activate them, and they will be compiled into the library.
|
||||
|
||||
You will need recent versions of several GNU tools: definitely GCC
|
||||
and GNU Make, and possibly others. *Note Tools for Compilation::,
|
||||
below.
|
||||
|
||||
Configuring and compiling GNU Libc
|
||||
==================================
|
||||
Configuring and compiling the GNU C Library
|
||||
===========================================
|
||||
|
||||
GNU libc cannot be compiled in the source directory. You must build it
|
||||
in a separate build directory. For example, if you have unpacked the
|
||||
glibc sources in `/src/gnu/glibc-VERSION', create a directory
|
||||
`/src/gnu/glibc-build' to put the object files in. This allows
|
||||
removing the whole build directory in case an error occurs, which is
|
||||
the safest way to get a fresh start and should always be done.
|
||||
The GNU C Library cannot be compiled in the source directory. You must
|
||||
build it in a separate build directory. For example, if you have
|
||||
unpacked the GNU C Library sources in `/src/gnu/glibc-VERSION', create
|
||||
a directory `/src/gnu/glibc-build' to put the object files in. This
|
||||
allows removing the whole build directory in case an error occurs,
|
||||
which is the safest way to get a fresh start and should always be done.
|
||||
|
||||
From your object directory, run the shell script `configure' located
|
||||
at the top level of the source tree. In the scenario above, you'd type
|
||||
@ -36,10 +36,10 @@ directory, especially some files in the manual subdirectory.
|
||||
|
||||
`configure' takes many options, but the only one that is usually
|
||||
mandatory is `--prefix'. This option tells `configure' where you want
|
||||
glibc installed. This defaults to `/usr/local', but the normal setting
|
||||
to install as the standard system library is `--prefix=/usr' for
|
||||
GNU/Linux systems and `--prefix=' (an empty prefix) for GNU/Hurd
|
||||
systems.
|
||||
the GNU C Library installed. This defaults to `/usr/local', but the
|
||||
normal setting to install as the standard system library is
|
||||
`--prefix=/usr' for GNU/Linux systems and `--prefix=' (an empty prefix)
|
||||
for GNU/Hurd systems.
|
||||
|
||||
It may also be useful to set the CC and CFLAGS variables in the
|
||||
environment when running `configure'. CC selects the C compiler that
|
||||
@ -59,16 +59,16 @@ will be used, and CFLAGS sets optimization options for the compiler.
|
||||
|
||||
`--with-headers=DIRECTORY'
|
||||
Look for kernel header files in DIRECTORY, not `/usr/include'.
|
||||
Glibc needs information from the kernel's header files describing
|
||||
the interface to the kernel. Glibc will normally look in
|
||||
`/usr/include' for them, but if you specify this option, it will
|
||||
look in DIRECTORY instead.
|
||||
The GNU C Library needs information from the kernel's header files
|
||||
describing the interface to the kernel. The GNU C Library will
|
||||
normally look in `/usr/include' for them, but if you specify this
|
||||
option, it will look in DIRECTORY instead.
|
||||
|
||||
This option is primarily of use on a system where the headers in
|
||||
`/usr/include' come from an older version of glibc. Conflicts can
|
||||
occasionally happen in this case. You can also use this option if
|
||||
you want to compile glibc with a newer set of kernel headers than
|
||||
the ones found in `/usr/include'.
|
||||
`/usr/include' come from an older version of the GNU C Library.
|
||||
Conflicts can occasionally happen in this case. You can also use
|
||||
this option if you want to compile the GNU C Library with a newer
|
||||
set of kernel headers than the ones found in `/usr/include'.
|
||||
|
||||
`--enable-add-ons[=LIST]'
|
||||
Specify add-on packages to include in the build. If this option is
|
||||
@ -93,7 +93,7 @@ will be used, and CFLAGS sets optimization options for the compiler.
|
||||
Use the binutils (assembler and linker) in `DIRECTORY', not the
|
||||
ones the C compiler would default to. You can use this option if
|
||||
the default binutils on your system cannot deal with all the
|
||||
constructs in the GNU C library. In that case, `configure' will
|
||||
constructs in the GNU C Library. In that case, `configure' will
|
||||
detect the problem and suppress these constructs, so that the
|
||||
library will still be usable, but functionality may be lost--for
|
||||
example, you can't build a shared libc with old binutils.
|
||||
@ -132,10 +132,10 @@ will be used, and CFLAGS sets optimization options for the compiler.
|
||||
`--host=HOST-SYSTEM'
|
||||
These options are for cross-compiling. If you specify both
|
||||
options and BUILD-SYSTEM is different from HOST-SYSTEM, `configure'
|
||||
will prepare to cross-compile glibc from BUILD-SYSTEM to be used
|
||||
on HOST-SYSTEM. You'll probably need the `--with-headers' option
|
||||
too, and you may have to override CONFIGURE's selection of the
|
||||
compiler and/or binutils.
|
||||
will prepare to cross-compile the GNU C Library from BUILD-SYSTEM
|
||||
to be used on HOST-SYSTEM. You'll probably need the
|
||||
`--with-headers' option too, and you may have to override
|
||||
CONFIGURE's selection of the compiler and/or binutils.
|
||||
|
||||
If you only specify `--host', `configure' will prepare for a
|
||||
native compile but use what you specify instead of guessing what
|
||||
@ -167,8 +167,8 @@ facilities, type `make check'. If it does not complete successfully,
|
||||
do not use the built library, and report a bug after verifying that the
|
||||
problem is not already known. *Note Reporting Bugs::, for instructions
|
||||
on reporting bugs. Note that some of the tests assume they are not
|
||||
being run by `root'. We recommend you compile and test glibc as an
|
||||
unprivileged user.
|
||||
being run by `root'. We recommend you compile and test the GNU C
|
||||
Library as an unprivileged user.
|
||||
|
||||
Before reporting bugs make sure there is no problem with your system.
|
||||
The tests (and later installation) use some pre-existing files of the
|
||||
@ -188,7 +188,7 @@ build directory and add values as appropriate for your system. The
|
||||
file is included and parsed by `make' and has to follow the conventions
|
||||
for makefiles.
|
||||
|
||||
It is easy to configure the GNU C library for cross-compilation by
|
||||
It is easy to configure the GNU C Library for cross-compilation by
|
||||
setting a few variables in `configparms'. Set `CC' to the
|
||||
cross-compiler for the target you configured the library for; it is
|
||||
important to use this same `CC' value when running `configure', like
|
||||
@ -204,16 +204,16 @@ Installing the C Library
|
||||
To install the library and its header files, and the Info files of the
|
||||
manual, type `env LANGUAGE=C LC_ALL=C make install'. This will build
|
||||
things, if necessary, before installing them; however, you should still
|
||||
compile everything first. If you are installing glibc as your primary
|
||||
C library, we recommend that you shut the system down to single-user
|
||||
mode first, and reboot afterward. This minimizes the risk of breaking
|
||||
things when the library changes out from underneath.
|
||||
compile everything first. If you are installing the GNU C Library as
|
||||
your primary C library, we recommend that you shut the system down to
|
||||
single-user mode first, and reboot afterward. This minimizes the risk
|
||||
of breaking things when the library changes out from underneath.
|
||||
|
||||
`make install' will do the entire job of upgrading from a previous
|
||||
installation of glibc 2.x. There may sometimes be headers left behind
|
||||
from the previous installation, but those are generally harmless. If
|
||||
you want to avoid leaving headers behind you can do things in the
|
||||
following order.
|
||||
installation of the GNU C Library version 2.x. There may sometimes be
|
||||
headers left behind from the previous installation, but those are
|
||||
generally harmless. If you want to avoid leaving headers behind you
|
||||
can do things in the following order.
|
||||
|
||||
You must first build the library (`make'), optionally check it
|
||||
(`make check'), switch the include directories and then install (`make
|
||||
@ -224,19 +224,20 @@ library requires the ability to compile and run programs against the old
|
||||
library. The new `/usr/include', after switching the include
|
||||
directories and before installing the library should contain the Linux
|
||||
headers, but nothing else. If you do this, you will need to restore
|
||||
any headers from non-glibc libraries youself after installing the
|
||||
library.
|
||||
any headers from libraries other than the GNU C Library yourself after
|
||||
installing the library.
|
||||
|
||||
You can install glibc somewhere other than where you configured it
|
||||
to go by setting the `install_root' variable on the command line for
|
||||
`make install'. The value of this variable is prepended to all the
|
||||
paths for installation. This is useful when setting up a chroot
|
||||
environment or preparing a binary distribution. The directory should be
|
||||
specified with an absolute file name.
|
||||
You can install the GNU C Library somewhere other than where you
|
||||
configured it to go by setting the `install_root' variable on the
|
||||
command line for `make install'. The value of this variable is
|
||||
prepended to all the paths for installation. This is useful when
|
||||
setting up a chroot environment or preparing a binary distribution.
|
||||
The directory should be specified with an absolute file name.
|
||||
|
||||
Glibc includes a daemon called `nscd', which you may or may not want
|
||||
to run. `nscd' caches name service lookups; it can dramatically
|
||||
improve performance with NIS+, and may help with DNS as well.
|
||||
The GNU C Library includes a daemon called `nscd', which you may or
|
||||
may not want to run. `nscd' caches name service lookups; it can
|
||||
dramatically improve performance with NIS+, and may help with DNS as
|
||||
well.
|
||||
|
||||
One auxiliary program, `/usr/libexec/pt_chown', is installed setuid
|
||||
`root'. This program is invoked by the `grantpt' function; it sets the
|
||||
@ -249,12 +250,12 @@ this program; otherwise you do. The source for `pt_chown' is in
|
||||
`login/programs/pt_chown.c'.
|
||||
|
||||
After installation you might want to configure the timezone and
|
||||
locale installation of your system. The GNU C library comes with a
|
||||
locale installation of your system. The GNU C Library comes with a
|
||||
locale database which gets configured with `localedef'. For example, to
|
||||
set up a German locale with name `de_DE', simply issue the command
|
||||
`localedef -i de_DE -f ISO-8859-1 de_DE'. To configure all locales
|
||||
that are supported by glibc, you can issue from your build directory the
|
||||
command `make localedata/install-locales'.
|
||||
that are supported by the GNU C Library, you can issue from your build
|
||||
directory the command `make localedata/install-locales'.
|
||||
|
||||
To configure the locally used timezone, set the `TZ' environment
|
||||
variable. The script `tzselect' helps you to select the right value.
|
||||
@ -269,7 +270,7 @@ Recommended Tools for Compilation
|
||||
=================================
|
||||
|
||||
We recommend installing the following GNU tools before attempting to
|
||||
build the GNU C library:
|
||||
build the GNU C Library:
|
||||
|
||||
* GNU `make' 3.79 or newer
|
||||
|
||||
@ -282,17 +283,17 @@ build the GNU C library:
|
||||
* GCC 4.3 or newer, GCC 4.6 recommended
|
||||
|
||||
GCC 4.3 or higher is required; as of this writing, GCC 4.6 is the
|
||||
compiler we advise to use to build the GNU C library.
|
||||
compiler we advise to use to build the GNU C Library.
|
||||
|
||||
You can use whatever compiler you like to compile programs that
|
||||
use GNU libc.
|
||||
You can use whatever compiler you like to compile programs that use
|
||||
the GNU C Library.
|
||||
|
||||
Check the FAQ for any special compiler issues on particular
|
||||
platforms.
|
||||
|
||||
* GNU `binutils' 2.15 or later
|
||||
|
||||
You must use GNU `binutils' (as and ld) to build the GNU C library.
|
||||
You must use GNU `binutils' (as and ld) to build the GNU C Library.
|
||||
No other assembler or linker has the necessary functionality at the
|
||||
moment.
|
||||
|
||||
@ -338,41 +339,42 @@ patches, although we try to avoid this.
|
||||
Specific advice for GNU/Linux systems
|
||||
=====================================
|
||||
|
||||
If you are installing GNU libc on a GNU/Linux system, you need to have
|
||||
the header files from a 2.6.19.1 or newer kernel around for reference.
|
||||
These headers must be installed using `make headers_install'; the
|
||||
headers present in the kernel source directory are not suitable for
|
||||
direct use by GNU libc. You do not need to use that kernel, just have
|
||||
its headers installed where glibc can access them, referred to here as
|
||||
INSTALL-DIRECTORY. The easiest way to do this is to unpack it in a
|
||||
directory such as `/usr/src/linux-VERSION'. In that directory, run
|
||||
`make headers_install INSTALL_HDR_PATH=INSTALL-DIRECTORY'. Finally,
|
||||
configure glibc with the option
|
||||
`--with-headers=INSTALL-DIRECTORY/include'. Use the most recent kernel
|
||||
you can get your hands on. (If you are cross-compiling GNU libc, you
|
||||
need to specify `ARCH=ARCHITECTURE' in the `make headers_install'
|
||||
command, where ARCHITECTURE is the architecture name used by the Linux
|
||||
kernel, such as `x86' or `powerpc'.)
|
||||
If you are installing the GNU C Library on a GNU/Linux system, you need
|
||||
to have the header files from a 2.6.19.1 or newer kernel around for
|
||||
reference. These headers must be installed using `make
|
||||
headers_install'; the headers present in the kernel source directory
|
||||
are not suitable for direct use by the GNU C Library. You do not need
|
||||
to use that kernel, just have its headers installed where the GNU C
|
||||
Library can access them, referred to here as INSTALL-DIRECTORY. The
|
||||
easiest way to do this is to unpack it in a directory such as
|
||||
`/usr/src/linux-VERSION'. In that directory, run `make headers_install
|
||||
INSTALL_HDR_PATH=INSTALL-DIRECTORY'. Finally, configure the GNU C
|
||||
Library with the option `--with-headers=INSTALL-DIRECTORY/include'.
|
||||
Use the most recent kernel you can get your hands on. (If you are
|
||||
cross-compiling the GNU C Library, you need to specify
|
||||
`ARCH=ARCHITECTURE' in the `make headers_install' command, where
|
||||
ARCHITECTURE is the architecture name used by the Linux kernel, such as
|
||||
`x86' or `powerpc'.)
|
||||
|
||||
After installing GNU libc, you may need to remove or rename
|
||||
After installing the GNU C Library, you may need to remove or rename
|
||||
directories such as `/usr/include/linux' and `/usr/include/asm', and
|
||||
replace them with copies of directories such as `linux' and `asm' from
|
||||
`INSTALL-DIRECTORY/include'. All directories present in
|
||||
`INSTALL-DIRECTORY/include' should be copied, except that GNU libc
|
||||
provides its own version of `/usr/include/scsi'; the files provided by
|
||||
the kernel should be copied without replacing those provided by GNU
|
||||
libc. The `linux', `asm' and `asm-generic' directories are required to
|
||||
compile programs using GNU libc; the other directories describe
|
||||
interfaces to the kernel but are not required if not compiling programs
|
||||
using those interfaces. You do not need to copy kernel headers if you
|
||||
did not specify an alternate kernel header source using
|
||||
`--with-headers'.
|
||||
`INSTALL-DIRECTORY/include' should be copied, except that the GNU C
|
||||
Library provides its own version of `/usr/include/scsi'; the files
|
||||
provided by the kernel should be copied without replacing those
|
||||
provided by the GNU C Library. The `linux', `asm' and `asm-generic'
|
||||
directories are required to compile programs using the GNU C Library;
|
||||
the other directories describe interfaces to the kernel but are not
|
||||
required if not compiling programs using those interfaces. You do not
|
||||
need to copy kernel headers if you did not specify an alternate kernel
|
||||
header source using `--with-headers'.
|
||||
|
||||
GNU/Linux expects some components of the libc installation to be in
|
||||
`/lib' and some in `/usr/lib'. This is handled automatically if you
|
||||
configure glibc with `--prefix=/usr'. If you set some other prefix or
|
||||
allow it to default to `/usr/local', then all the components are
|
||||
installed there.
|
||||
GNU/Linux expects some components of the GNU C Library installation
|
||||
to be in `/lib' and some in `/usr/lib'. This is handled automatically
|
||||
if you configure the GNU C Library with `--prefix=/usr'. If you set
|
||||
some other prefix or allow it to default to `/usr/local', then all the
|
||||
components are installed there.
|
||||
|
||||
You cannot use `nscd' with 2.0 kernels, due to bugs in the
|
||||
kernel-side thread support. `nscd' happens to hit these bugs
|
||||
@ -382,7 +384,7 @@ program.
|
||||
Reporting Bugs
|
||||
==============
|
||||
|
||||
There are probably bugs in the GNU C library. There are certainly
|
||||
There are probably bugs in the GNU C Library. There are certainly
|
||||
errors and omissions in this manual. If you report them, they will get
|
||||
fixed. If you don't, no one will ever know about them and they will
|
||||
remain unfixed for all eternity, if not longer.
|
||||
@ -396,14 +398,14 @@ includes a patch or a hint on solving the problem.
|
||||
|
||||
To report a bug, first you must find it. With any luck, this will
|
||||
be the hard part. Once you've found a bug, make sure it's really a
|
||||
bug. A good way to do this is to see if the GNU C library behaves the
|
||||
bug. A good way to do this is to see if the GNU C Library behaves the
|
||||
same way some other C library does. If so, probably you are wrong and
|
||||
the libraries are right (but not necessarily). If not, one of the
|
||||
libraries is probably wrong. It might not be the GNU library. Many
|
||||
libraries is probably wrong. It might not be the GNU C Library. Many
|
||||
historical Unix C libraries permit things that we don't, such as
|
||||
closing a file twice.
|
||||
|
||||
If you think you have found some way in which the GNU C library does
|
||||
If you think you have found some way in which the GNU C Library does
|
||||
not conform to the ISO and POSIX standards (*note Standards and
|
||||
Portability::), that is definitely a bug. Report it!
|
||||
|
||||
|
4
Makefile
4
Makefile
@ -398,8 +398,8 @@ define format-me
|
||||
makeinfo --no-validate --plaintext --no-number-sections $< -o $@
|
||||
-chmod a-w $@
|
||||
endef
|
||||
INSTALL: manual/install.texi; $(format-me)
|
||||
NOTES: manual/creature.texi; $(format-me)
|
||||
INSTALL: manual/install.texi manual/macros.texi; $(format-me)
|
||||
NOTES: manual/creature.texi manual/macros.texi; $(format-me)
|
||||
manual/dir-add.texi manual/dir-add.info: FORCE
|
||||
$(MAKE) $(PARALLELMFLAGS) -C $(@D) $(@F)
|
||||
FAQ: scripts/gen-FAQ.pl FAQ.in
|
||||
|
12
NOTES
12
NOTES
@ -164,9 +164,9 @@ relying on semantics undefined within the standard.
|
||||
|
||||
-- Macro: _ISOC99_SOURCE
|
||||
Until the revised ISO C standard is widely adopted the new features
|
||||
are not automatically enabled. The GNU libc nevertheless has a
|
||||
complete implementation of the new standard and to enable the new
|
||||
features the macro `_ISOC99_SOURCE' should be defined.
|
||||
are not automatically enabled. The GNU C Library nevertheless has
|
||||
a complete implementation of the new standard and to enable the
|
||||
new features the macro `_ISOC99_SOURCE' should be defined.
|
||||
|
||||
-- Macro: _GNU_SOURCE
|
||||
If you define this macro, everything is included: ISO C89,
|
||||
@ -184,7 +184,7 @@ relying on semantics undefined within the standard.
|
||||
|
||||
Note that if you do this, you must link your program with the BSD
|
||||
compatibility library by passing the `-lbsd-compat' option to the
|
||||
compiler or linker. *Note:* If you forget to do this, you may get
|
||||
compiler or linker. *NB:* If you forget to do this, you may get
|
||||
very strange errors at run time.
|
||||
|
||||
-- Macro: _REENTRANT
|
||||
@ -192,8 +192,8 @@ relying on semantics undefined within the standard.
|
||||
If you define one of these macros, reentrant versions of several
|
||||
functions get declared. Some of the functions are specified in
|
||||
POSIX.1c but many others are only available on a few other systems
|
||||
or are unique to GNU libc. The problem is the delay in the
|
||||
standardization of the thread safe C library interface.
|
||||
or are unique to the GNU C Library. The problem is the delay in
|
||||
the standardization of the thread safe C library interface.
|
||||
|
||||
Unlike on some other systems, no special version of the C library
|
||||
must be used for linking. There is only one version but while
|
||||
|
@ -40,9 +40,9 @@ this is that a program often needs to be written for a particular range
|
||||
of integers, and sometimes must be written for a particular size of
|
||||
storage, regardless of what machine the program runs on.
|
||||
|
||||
To address this problem, the GNU C library contains C type definitions
|
||||
To address this problem, @theglibc{} contains C type definitions
|
||||
you can use to declare integers that meet your exact needs. Because the
|
||||
GNU C library header files are customized to a specific machine, your
|
||||
@glibcadj{} header files are customized to a specific machine, your
|
||||
program source code doesn't have to be.
|
||||
|
||||
These @code{typedef}s are in @file{stdint.h}.
|
||||
@ -105,7 +105,7 @@ of the integer.
|
||||
@item uintmax_t
|
||||
@end itemize
|
||||
|
||||
The GNU C library also provides macros that tell you the maximum and
|
||||
@Theglibc{} also provides macros that tell you the maximum and
|
||||
minimum possible values for each integer data type. The macro names
|
||||
follow these examples: @code{INT32_MAX}, @code{UINT8_MAX},
|
||||
@code{INT_FAST32_MIN}, @code{INT_LEAST64_MIN}, @code{UINTMAX_MAX},
|
||||
@ -388,7 +388,7 @@ to
|
||||
@end deftypefn
|
||||
|
||||
Another set of floating-point classification functions was provided by
|
||||
BSD. The GNU C library also supports these functions; however, we
|
||||
BSD. @Theglibc{} also supports these functions; however, we
|
||||
recommend that you use the ISO C99 macros in new code. Those are standard
|
||||
and will be available more widely. Also, since they are macros, you do
|
||||
not have to worry about the type of their argument.
|
||||
@ -1019,7 +1019,7 @@ Implementation defined macros with names starting with @code{FE_} and
|
||||
having type @code{fenv_t *}.
|
||||
|
||||
@vindex FE_NOMASK_ENV
|
||||
If possible, the GNU C Library defines a macro @code{FE_NOMASK_ENV}
|
||||
If possible, @theglibc{} defines a macro @code{FE_NOMASK_ENV}
|
||||
which represents an environment where every exception raised causes a
|
||||
trap to occur. You can test for this macro using @code{#ifdef}. It is
|
||||
only defined if @code{_GNU_SOURCE} is defined.
|
||||
@ -1813,7 +1813,7 @@ On processors which do not implement multiply-add in hardware,
|
||||
@file{math.h} defines the symbols @code{FP_FAST_FMA},
|
||||
@code{FP_FAST_FMAF}, and @code{FP_FAST_FMAL} when the corresponding
|
||||
version of @code{fma} is no slower than the expression @samp{x*y + z}.
|
||||
In the GNU C library, this always means the operation is implemented in
|
||||
In @theglibc{}, this always means the operation is implemented in
|
||||
hardware.
|
||||
@end deftypefun
|
||||
|
||||
@ -2445,7 +2445,7 @@ is provided mostly for compatibility with existing code; using
|
||||
@code{strtod} is more robust.
|
||||
@end deftypefun
|
||||
|
||||
The GNU C library also provides @samp{_l} versions of these functions,
|
||||
@Theglibc{} also provides @samp{_l} versions of these functions,
|
||||
which take an additional argument, the locale to use in conversion.
|
||||
@xref{Parsing of Integers}.
|
||||
|
||||
@ -2453,10 +2453,10 @@ which take an additional argument, the locale to use in conversion.
|
||||
@section Old-fashioned System V number-to-string functions
|
||||
|
||||
The old @w{System V} C library provided three functions to convert
|
||||
numbers to strings, with unusual and hard-to-use semantics. The GNU C
|
||||
library also provides these functions and some natural extensions.
|
||||
numbers to strings, with unusual and hard-to-use semantics. @Theglibc{}
|
||||
also provides these functions and some natural extensions.
|
||||
|
||||
These functions are only available in glibc and on systems descended
|
||||
These functions are only available in @theglibc{} and on systems descended
|
||||
from AT&T Unix. Therefore, unless these functions do precisely what you
|
||||
need, it is better to use @code{sprintf}, which is standard.
|
||||
|
||||
@ -2516,7 +2516,7 @@ If @var{ndigit} decimal digits would exceed the precision of a
|
||||
@code{double} it is reduced to a system-specific value.
|
||||
@end deftypefun
|
||||
|
||||
As extensions, the GNU C library provides versions of these three
|
||||
As extensions, @theglibc{} provides versions of these three
|
||||
functions that take @code{long double} arguments.
|
||||
|
||||
@comment stdlib.h
|
||||
@ -2547,7 +2547,7 @@ restricted by the precision of a @code{long double}.
|
||||
@cindex gcvt_r
|
||||
The @code{ecvt} and @code{fcvt} functions, and their @code{long double}
|
||||
equivalents, all return a string located in a static buffer which is
|
||||
overwritten by the next call to the function. The GNU C library
|
||||
overwritten by the next call to the function. @Theglibc{}
|
||||
provides another set of extended functions which write the converted
|
||||
string into a user-supplied buffer. These have the conventional
|
||||
@code{_r} suffix.
|
||||
|
@ -361,7 +361,7 @@ the @code{LC_CTYPE} category of the current locale is used; see
|
||||
The functions handling more than one character at a time require NUL
|
||||
terminated strings as the argument (i.e., converting blocks of text
|
||||
does not work unless one can add a NUL byte at an appropriate place).
|
||||
The GNU C library contains some extensions to the standard that allow
|
||||
@Theglibc{} contains some extensions to the standard that allow
|
||||
specifying a size, but basically they also expect terminated strings.
|
||||
@end itemize
|
||||
|
||||
@ -418,7 +418,7 @@ a compile-time constant and is defined in @file{limits.h}.
|
||||
maximum number of bytes in a multibyte character in the current locale.
|
||||
The value is never greater than @code{MB_LEN_MAX}. Unlike
|
||||
@code{MB_LEN_MAX} this macro need not be a compile-time constant, and in
|
||||
the GNU C library it is not.
|
||||
@theglibc{} it is not.
|
||||
|
||||
@pindex stdlib.h
|
||||
@code{MB_CUR_MAX} is defined in @file{stdlib.h}.
|
||||
@ -793,7 +793,7 @@ character sequence but the one representing the NUL wide character.
|
||||
Therefore, the @code{mbrlen} function will never read invalid memory.
|
||||
|
||||
Now that this function is available (just to make this clear, this
|
||||
function is @emph{not} part of the GNU C library) we can compute the
|
||||
function is @emph{not} part of @theglibc{}) we can compute the
|
||||
number of wide character required to store the converted multibyte
|
||||
character string @var{s} using
|
||||
|
||||
@ -949,7 +949,7 @@ The functions described in the previous section only convert a single
|
||||
character at a time. Most operations to be performed in real-world
|
||||
programs include strings and therefore the @w{ISO C} standard also
|
||||
defines conversions on entire strings. However, the defined set of
|
||||
functions is quite limited; therefore, the GNU C library contains a few
|
||||
functions is quite limited; therefore, @theglibc{} contains a few
|
||||
extensions that can help in some important situations.
|
||||
|
||||
@comment wchar.h
|
||||
@ -1030,7 +1030,7 @@ therefore, should never be used in generally used code.
|
||||
|
||||
The generic conversion interface (@pxref{Generic Charset Conversion})
|
||||
does not have this limitation (it simply works on buffers, not
|
||||
strings), and the GNU C library contains a set of functions that take
|
||||
strings), and @theglibc{} contains a set of functions that take
|
||||
additional parameters specifying the maximal number of bytes that are
|
||||
consumed from the input string. This way the problem of
|
||||
@code{mbsrtowcs}'s example above could be solved by determining the line
|
||||
@ -1528,8 +1528,8 @@ The conversion functions mentioned so far in this chapter all had in
|
||||
common that they operate on character sets that are not directly
|
||||
specified by the functions. The multibyte encoding used is specified by
|
||||
the currently selected locale for the @code{LC_CTYPE} category. The
|
||||
wide character set is fixed by the implementation (in the case of GNU C
|
||||
library it is always UCS-4 encoded @w{ISO 10646}.
|
||||
wide character set is fixed by the implementation (in the case of @theglibc{}
|
||||
it is always UCS-4 encoded @w{ISO 10646}.
|
||||
|
||||
This has of course several problems when it comes to general character
|
||||
conversion:
|
||||
@ -1648,7 +1648,7 @@ An @code{iconv} descriptor is like a file descriptor as for every use a
|
||||
new descriptor must be created. The descriptor does not stand for all
|
||||
of the conversions from @var{fromset} to @var{toset}.
|
||||
|
||||
The GNU C library implementation of @code{iconv_open} has one
|
||||
The @glibcadj{} implementation of @code{iconv_open} has one
|
||||
significant extension to other implementations. To ease the extension
|
||||
of the set of available conversions, the implementation allows storing
|
||||
the necessary files with data and code in an arbitrary number of
|
||||
@ -1740,7 +1740,7 @@ from the initial state. It is important that the programmer never makes
|
||||
any assumption as to whether the conversion has to deal with states.
|
||||
Even if the input and output character sets are not stateful, the
|
||||
implementation might still have to keep states. This is due to the
|
||||
implementation chosen for the GNU C library as it is described below.
|
||||
implementation chosen for @theglibc{} as it is described below.
|
||||
Therefore an @code{iconv} call to reset the state should always be
|
||||
performed if some protocol requires this for the output text.
|
||||
|
||||
@ -1761,7 +1761,7 @@ Since the character sets selected in the @code{iconv_open} call can be
|
||||
almost arbitrary, there can be situations where the input buffer contains
|
||||
valid characters, which have no identical representation in the output
|
||||
character set. The behavior in this situation is undefined. The
|
||||
@emph{current} behavior of the GNU C library in this situation is to
|
||||
@emph{current} behavior of @theglibc{} in this situation is to
|
||||
return with an error immediately. This certainly is not the most
|
||||
desirable solution; therefore, future versions will provide better ones,
|
||||
but they are not yet finished.
|
||||
@ -1980,7 +1980,7 @@ the door open for extensions and improvements, but this design is also
|
||||
limiting on some platforms since not many platforms support dynamic
|
||||
loading in statically linked programs. On platforms without this
|
||||
capability it is therefore not possible to use this interface in
|
||||
statically linked programs. The GNU C library has, on ELF platforms, no
|
||||
statically linked programs. @Theglibc{} has, on ELF platforms, no
|
||||
problems with dynamic loading in these situations; therefore, this
|
||||
point is moot. The danger is that one gets acquainted with this
|
||||
situation and forgets about the restrictions on other systems.
|
||||
@ -2054,38 +2054,38 @@ such conversion, one could make sure this also is true for indirect
|
||||
routes.
|
||||
|
||||
@node glibc iconv Implementation
|
||||
@subsection The @code{iconv} Implementation in the GNU C library
|
||||
@subsection The @code{iconv} Implementation in @theglibc{}
|
||||
|
||||
After reading about the problems of @code{iconv} implementations in the
|
||||
last section it is certainly good to note that the implementation in
|
||||
the GNU C library has none of the problems mentioned above. What
|
||||
@theglibc{} has none of the problems mentioned above. What
|
||||
follows is a step-by-step analysis of the points raised above. The
|
||||
evaluation is based on the current state of the development (as of
|
||||
January 1999). The development of the @code{iconv} functions is not
|
||||
complete, but basic functionality has solidified.
|
||||
|
||||
The GNU C library's @code{iconv} implementation uses shared loadable
|
||||
@Theglibc{}'s @code{iconv} implementation uses shared loadable
|
||||
modules to implement the conversions. A very small number of
|
||||
conversions are built into the library itself but these are only rather
|
||||
trivial conversions.
|
||||
|
||||
All the benefits of loadable modules are available in the GNU C library
|
||||
All the benefits of loadable modules are available in the @glibcadj{}
|
||||
implementation. This is especially appealing since the interface is
|
||||
well documented (see below), and it, therefore, is easy to write new
|
||||
conversion modules. The drawback of using loadable objects is not a
|
||||
problem in the GNU C library, at least on ELF systems. Since the
|
||||
problem in @theglibc{}, at least on ELF systems. Since the
|
||||
library is able to load shared objects even in statically linked
|
||||
binaries, static linking need not be forbidden in case one wants to use
|
||||
@code{iconv}.
|
||||
|
||||
The second mentioned problem is the number of supported conversions.
|
||||
Currently, the GNU C library supports more than 150 character sets. The
|
||||
Currently, @theglibc{} supports more than 150 character sets. The
|
||||
way the implementation is designed the number of supported conversions
|
||||
is greater than 22350 (@math{150} times @math{149}). If any conversion
|
||||
from or to a character set is missing, it can be added easily.
|
||||
|
||||
Particularly impressive as it may be, this high number is due to the
|
||||
fact that the GNU C library implementation of @code{iconv} does not have
|
||||
fact that the @glibcadj{} implementation of @code{iconv} does not have
|
||||
the third problem mentioned above (i.e., whenever there is a conversion
|
||||
from a character set @math{@cal{A}} to @math{@cal{B}} and from
|
||||
@math{@cal{B}} to @math{@cal{C}} it is always possible to convert from
|
||||
@ -2115,7 +2115,7 @@ the input to @w{ISO 10646} first. The two character sets of interest
|
||||
are much more similar to each other than to @w{ISO 10646}.
|
||||
|
||||
In such a situation one easily can write a new conversion and provide it
|
||||
as a better alternative. The GNU C library @code{iconv} implementation
|
||||
as a better alternative. The @glibcadj{} @code{iconv} implementation
|
||||
would automatically use the module implementing the conversion if it is
|
||||
specified to be more efficient.
|
||||
|
||||
@ -2207,7 +2207,7 @@ file, however, specifies that the new conversion modules can perform this
|
||||
conversion with only the cost of @math{1}.
|
||||
|
||||
A mysterious item about the @file{gconv-modules} file above (and also
|
||||
the file coming with the GNU C library) are the names of the character
|
||||
the file coming with @theglibc{}) are the names of the character
|
||||
sets specified in the @code{module} lines. Why do almost all the names
|
||||
end in @code{//}? And this is not all: the names can actually be
|
||||
regular expressions. At this point in time this mystery should not be
|
||||
@ -2423,7 +2423,7 @@ loads the objects with the conversions.
|
||||
It is often the case that one conversion is used more than once (i.e.,
|
||||
there are several @code{iconv_open} calls for the same set of character
|
||||
sets during one program run). The @code{mbsrtowcs} et.al.@: functions in
|
||||
the GNU C library also use the @code{iconv} functionality, which
|
||||
@theglibc{} also use the @code{iconv} functionality, which
|
||||
increases the number of uses of the same functions even more.
|
||||
|
||||
Because of this multiple use of conversions, the modules do not get
|
||||
@ -2888,8 +2888,8 @@ gconv (struct __gconv_step *step, struct __gconv_step_data *data,
|
||||
@end deftypevr
|
||||
|
||||
This information should be sufficient to write new modules. Anybody
|
||||
doing so should also take a look at the available source code in the GNU
|
||||
C library sources. It contains many examples of working and optimized
|
||||
doing so should also take a look at the available source code in the
|
||||
@glibcadj{} sources. It contains many examples of working and optimized
|
||||
modules.
|
||||
|
||||
@c File charset.texi edited October 2001 by Dennis Grace, IBM Corporation
|
||||
|
@ -147,7 +147,7 @@ should always be defined even if there is no specific imposed limit.
|
||||
|
||||
POSIX defines certain system-specific options that not all POSIX systems
|
||||
support. Since these options are provided in the kernel, not in the
|
||||
library, simply using the GNU C library does not guarantee any of these
|
||||
library, simply using @theglibc{} does not guarantee any of these
|
||||
features is supported; it depends on the system you are using.
|
||||
|
||||
@pindex unistd.h
|
||||
@ -190,7 +190,7 @@ to find out. @xref{Sysconf}.
|
||||
@comment POSIX.2
|
||||
@deftypevr Macro int _POSIX2_C_DEV
|
||||
If this symbol is defined, it indicates that the system has the POSIX.2
|
||||
C compiler command, @code{c89}. The GNU C library always defines this
|
||||
C compiler command, @code{c89}. @Theglibc{} always defines this
|
||||
as @code{1}, on the assumption that you would not have installed it if
|
||||
you didn't have a C compiler.
|
||||
@end deftypevr
|
||||
@ -199,7 +199,7 @@ you didn't have a C compiler.
|
||||
@comment POSIX.2
|
||||
@deftypevr Macro int _POSIX2_FORT_DEV
|
||||
If this symbol is defined, it indicates that the system has the POSIX.2
|
||||
Fortran compiler command, @code{fort77}. The GNU C library never
|
||||
Fortran compiler command, @code{fort77}. @Theglibc{} never
|
||||
defines this, because we don't know what the system has.
|
||||
@end deftypevr
|
||||
|
||||
@ -207,15 +207,15 @@ defines this, because we don't know what the system has.
|
||||
@comment POSIX.2
|
||||
@deftypevr Macro int _POSIX2_FORT_RUN
|
||||
If this symbol is defined, it indicates that the system has the POSIX.2
|
||||
@code{asa} command to interpret Fortran carriage control. The GNU C
|
||||
library never defines this, because we don't know what the system has.
|
||||
@code{asa} command to interpret Fortran carriage control. @Theglibc{}
|
||||
never defines this, because we don't know what the system has.
|
||||
@end deftypevr
|
||||
|
||||
@comment unistd.h
|
||||
@comment POSIX.2
|
||||
@deftypevr Macro int _POSIX2_LOCALEDEF
|
||||
If this symbol is defined, it indicates that the system has the POSIX.2
|
||||
@code{localedef} command. The GNU C library never defines this, because
|
||||
@code{localedef} command. @Theglibc{} never defines this, because
|
||||
we don't know what the system has.
|
||||
@end deftypevr
|
||||
|
||||
@ -223,7 +223,7 @@ we don't know what the system has.
|
||||
@comment POSIX.2
|
||||
@deftypevr Macro int _POSIX2_SW_DEV
|
||||
If this symbol is defined, it indicates that the system has the POSIX.2
|
||||
commands @code{ar}, @code{make}, and @code{strip}. The GNU C library
|
||||
commands @code{ar}, @code{make}, and @code{strip}. @Theglibc{}
|
||||
always defines this as @code{1}, on the assumption that you had to have
|
||||
@code{ar} and @code{make} to install the library, and it's unlikely that
|
||||
@code{strip} would be absent when those are present.
|
||||
@ -728,7 +728,7 @@ utilities can handle.
|
||||
@item _SC_EQUIV_CLASS_MAX
|
||||
Inquire about the maximum number of weights that can be assigned to an
|
||||
entry of the @code{LC_COLLATE} category @samp{order} keyword in a locale
|
||||
definition. The GNU C library does not presently support locale
|
||||
definition. @Theglibc{} does not presently support locale
|
||||
definitions.
|
||||
|
||||
@comment unistd.h
|
||||
@ -1198,7 +1198,7 @@ that big! Use dynamic allocation (@pxref{Memory Allocation}) instead.
|
||||
POSIX defines certain system-specific options in the system calls for
|
||||
operating on files. Some systems support these options and others do
|
||||
not. Since these options are provided in the kernel, not in the
|
||||
library, simply using the GNU C library does not guarantee that any of these
|
||||
library, simply using @theglibc{} does not guarantee that any of these
|
||||
features is supported; it depends on the system you are using. They can
|
||||
also vary between file systems on a single machine.
|
||||
|
||||
@ -1210,11 +1210,10 @@ corresponding feature is supported. (A value of @code{-1} indicates no;
|
||||
any other value indicates yes.) If the macro is undefined, it means
|
||||
particular files may or may not support the feature.
|
||||
|
||||
Since all the machines that support the GNU C library also support NFS,
|
||||
Since all the machines that support @theglibc{} also support NFS,
|
||||
one can never make a general statement about whether all file systems
|
||||
support the @code{_POSIX_CHOWN_RESTRICTED} and @code{_POSIX_NO_TRUNC}
|
||||
features. So these names are never defined as macros in the GNU C
|
||||
library.
|
||||
features. So these names are never defined as macros in @theglibc{}.
|
||||
|
||||
@comment unistd.h
|
||||
@comment POSIX.1
|
||||
@ -1482,7 +1481,7 @@ The POSIX.2 standard specifies certain system limits that you can access
|
||||
through @code{sysconf} that apply to utility behavior rather than the
|
||||
behavior of the library or the operating system.
|
||||
|
||||
The GNU C library defines macros for these limits, and @code{sysconf}
|
||||
@Theglibc{} defines macros for these limits, and @code{sysconf}
|
||||
returns values for them if you ask; but these values convey no
|
||||
meaningful information. They are simply the smallest values that
|
||||
POSIX.2 permits.
|
||||
@ -1543,7 +1542,7 @@ memory, but there is no way that the library can tell you this.)
|
||||
@deftypevr Macro int EQUIV_CLASS_MAX
|
||||
The maximum number of weights that can be assigned to an entry of the
|
||||
@code{LC_COLLATE} category @samp{order} keyword in a locale definition.
|
||||
The GNU C library does not presently support locale definitions.
|
||||
@Theglibc{} does not presently support locale definitions.
|
||||
@end deftypevr
|
||||
|
||||
@node Utility Minimums
|
||||
@ -1601,7 +1600,7 @@ a text line that the text utilities can handle. Its value is
|
||||
The most restrictive limit permitted by POSIX.2 for the maximum number
|
||||
of weights that can be assigned to an entry of the @code{LC_COLLATE}
|
||||
category @samp{order} keyword in a locale definition. Its value is
|
||||
@code{2}. The GNU C library does not presently support locale
|
||||
@code{2}. @Theglibc{} does not presently support locale
|
||||
definitions.
|
||||
@end table
|
||||
|
||||
|
@ -1,8 +1,8 @@
|
||||
@node Contributors, Free Manuals, Maintenance, Top
|
||||
@c %MENU% Who wrote what parts of the GNU C library
|
||||
@appendix Contributors to the GNU C Library
|
||||
@c %MENU% Who wrote what parts of the GNU C Library
|
||||
@appendix Contributors to @theglibc{}
|
||||
|
||||
The GNU C library was written originally by Roland McGrath, and is
|
||||
@Theglibc{} was written originally by Roland McGrath, and is
|
||||
currently maintained by Ulrich Drepper. Some parts of the library were
|
||||
contributed or worked on by other people.
|
||||
|
||||
@ -93,7 +93,7 @@ Roland McGrath, based on a backend interface defined by Peter Eriksson.
|
||||
@item
|
||||
The port to Linux i386/ELF (@code{i386-@var{anything}-linux}) was
|
||||
contributed by Ulrich Drepper, based in large part on work done in
|
||||
Hongjiu Lu's Linux version of the GNU C Library.
|
||||
Hongjiu Lu's Linux version of @theglibc{}.
|
||||
|
||||
@item
|
||||
The port to Linux/m68k (@code{m68k-@var{anything}-linux}) was
|
||||
@ -178,7 +178,7 @@ The random number generation functions @code{random}, @code{srandom},
|
||||
@code{rand} and @code{srand} functions, were written by Earl T. Cohen
|
||||
for the University of California at Berkeley and are copyrighted by the
|
||||
Regents of the University of California. They have undergone minor
|
||||
changes to fit into the GNU C library and to fit the @w{ISO C} standard,
|
||||
changes to fit into @theglibc{} and to fit the @w{ISO C} standard,
|
||||
but the functional code is Berkeley's.@refill
|
||||
|
||||
@item
|
||||
|
@ -1,5 +1,6 @@
|
||||
@node Feature Test Macros
|
||||
@subsection Feature Test Macros
|
||||
@include macros.texi
|
||||
|
||||
@cindex feature test macros
|
||||
The exact set of features available when you compile a source file
|
||||
@ -65,7 +66,7 @@ then the functionality from the 1993 edition of the POSIX.1b standard
|
||||
|
||||
Greater values for @code{_POSIX_C_SOURCE} will enable future extensions.
|
||||
The POSIX standards process will define these values as necessary, and
|
||||
the GNU C Library should support them some time after they become standardized.
|
||||
@theglibc{} should support them some time after they become standardized.
|
||||
The 1996 edition of POSIX.1 (ISO/IEC 9945-1: 1996) states that
|
||||
if you define @code{_POSIX_C_SOURCE} to a value greater than
|
||||
or equal to @code{199506L}, then the functionality from the 1996
|
||||
@ -192,7 +193,7 @@ This macro was introduced as part of the Large File Support extension
|
||||
@comment GNU
|
||||
@defvr Macro _ISOC99_SOURCE
|
||||
Until the revised @w{ISO C} standard is widely adopted the new features
|
||||
are not automatically enabled. The GNU libc nevertheless has a complete
|
||||
are not automatically enabled. @Theglibc{} nevertheless has a complete
|
||||
implementation of the new standard and to enable the new features the
|
||||
macro @code{_ISOC99_SOURCE} should be defined.
|
||||
@end defvr
|
||||
@ -227,7 +228,7 @@ get very strange errors at run time.
|
||||
@defvrx Macro _THREAD_SAFE
|
||||
If you define one of these macros, reentrant versions of several functions get
|
||||
declared. Some of the functions are specified in POSIX.1c but many others
|
||||
are only available on a few other systems or are unique to GNU libc.
|
||||
are only available on a few other systems or are unique to @theglibc{}.
|
||||
The problem is the delay in the standardization of the thread safe C library
|
||||
interface.
|
||||
|
||||
|
@ -23,7 +23,7 @@ through a @dfn{one-way function}, a function which makes it difficult to
|
||||
work out what its input was by looking at its output, before storing in
|
||||
the file.
|
||||
|
||||
The GNU C library provides a one-way function that is compatible with
|
||||
@Theglibc{} provides a one-way function that is compatible with
|
||||
the behavior of the @code{crypt} function introduced in FreeBSD 2.0.
|
||||
It supports two one-way algorithms: one based on the MD5
|
||||
message-digest algorithm that is compatible with modern BSD systems,
|
||||
@ -103,7 +103,7 @@ The terminal is flushed before and after @code{getpass}, so that
|
||||
characters of a mistyped password are not accidentally visible.
|
||||
|
||||
In other C libraries, @code{getpass} may only return the first
|
||||
@code{PASS_MAX} bytes of a password. The GNU C library has no limit, so
|
||||
@code{PASS_MAX} bytes of a password. @Theglibc{} has no limit, so
|
||||
@code{PASS_MAX} is undefined.
|
||||
|
||||
The prototype for this function is in @file{unistd.h}. @code{PASS_MAX}
|
||||
|
@ -273,7 +273,7 @@ The general design of the classification functions for wide characters
|
||||
is more general. It allows extensions to the set of available
|
||||
classifications, beyond those which are always available. The POSIX
|
||||
standard specifies how extensions can be made, and this is already
|
||||
implemented in the GNU C library implementation of the @code{localedef}
|
||||
implemented in the @glibcadj{} implementation of the @code{localedef}
|
||||
program.
|
||||
|
||||
The character class functions are normally implemented with bitsets,
|
||||
@ -589,7 +589,7 @@ iswctype (wc, wctype ("xdigit"))
|
||||
It is declared in @file{wctype.h}.
|
||||
@end deftypefun
|
||||
|
||||
The GNU C library also provides a function which is not defined in the
|
||||
@Theglibc{} also provides a function which is not defined in the
|
||||
@w{ISO C} standard but which is available as a version for single byte
|
||||
characters as well.
|
||||
|
||||
@ -607,7 +607,7 @@ It is declared in @file{wchar.h}.
|
||||
|
||||
The first note is probably not astonishing but still occasionally a
|
||||
cause of problems. The @code{isw@var{XXX}} functions can be implemented
|
||||
using macros and in fact, the GNU C library does this. They are still
|
||||
using macros and in fact, @theglibc{} does this. They are still
|
||||
available as real functions but when the @file{wctype.h} header is
|
||||
included the macros will be used. This is the same as the
|
||||
@code{char} type versions of these functions.
|
||||
|
@ -6,7 +6,7 @@
|
||||
@cindex error codes
|
||||
@cindex status codes
|
||||
|
||||
Many functions in the GNU C library detect and report error conditions,
|
||||
Many functions in @theglibc{} detect and report error conditions,
|
||||
and sometimes your programs need to check for these error conditions.
|
||||
For example, when you open an input file, you should verify that the
|
||||
file was actually opened correctly, and print an error message or take
|
||||
@ -67,7 +67,7 @@ function returns an error.
|
||||
``modifiable lvalue'' rather than as a variable, permitting it to be
|
||||
implemented as a macro. For example, its expansion might involve a
|
||||
function call, like @w{@code{*_errno ()}}. In fact, that is what it is
|
||||
on the GNU system itself. The GNU library, on non-GNU systems, does
|
||||
on the GNU system itself. @Theglibc{}, on non-GNU systems, does
|
||||
whatever is right for the particular system.
|
||||
|
||||
There are a few library functions, like @code{sqrt} and @code{atan},
|
||||
@ -114,8 +114,8 @@ allocated memory instead of stack memory on that system.
|
||||
@pindex errno.h
|
||||
The error code macros are defined in the header file @file{errno.h}.
|
||||
All of them expand into integer constant values. Some of these error
|
||||
codes can't occur on the GNU system, but they can occur using the GNU
|
||||
library on other systems.
|
||||
codes can't occur on the GNU system, but they can occur using @theglibc{}
|
||||
on other systems.
|
||||
|
||||
@comment errno.h
|
||||
@comment POSIX.1: Operation not permitted
|
||||
@ -419,7 +419,7 @@ not representable because of overflow or underflow.
|
||||
@comment errno 35 @c DO NOT REMOVE
|
||||
Resource temporarily unavailable; the call might work if you try again
|
||||
later. The macro @code{EWOULDBLOCK} is another name for @code{EAGAIN};
|
||||
they are always the same in the GNU C library.
|
||||
they are always the same in @theglibc{}.
|
||||
|
||||
This error can happen in a few different situations:
|
||||
|
||||
@ -452,7 +452,7 @@ and return to its command loop.
|
||||
@comment BSD: Operation would block
|
||||
@deftypevr Macro int EWOULDBLOCK
|
||||
@comment errno EAGAIN @c DO NOT REMOVE
|
||||
In the GNU C library, this is another name for @code{EAGAIN} (above).
|
||||
In @theglibc{}, this is another name for @code{EAGAIN} (above).
|
||||
The values are always the same, on every operating system.
|
||||
|
||||
C libraries in many older Unix systems have @code{EWOULDBLOCK} as a
|
||||
@ -1572,7 +1572,7 @@ like this:
|
||||
|
||||
@code{error} and @code{error_at_line} are clearly the functions of
|
||||
choice and enable the programmer to write applications which follow the
|
||||
GNU coding standard. The GNU libc additionally contains functions which
|
||||
GNU coding standard. @Theglibc{} additionally contains functions which
|
||||
are used in BSD for the same purpose. These functions are declared in
|
||||
@file{err.h}. It is generally advised to not use these functions. They
|
||||
are included only for compatibility.
|
||||
|
@ -2,7 +2,7 @@
|
||||
@c %MENU% Functions for manipulating files
|
||||
@chapter File System Interface
|
||||
|
||||
This chapter describes the GNU C library's functions for manipulating
|
||||
This chapter describes @theglibc{}'s functions for manipulating
|
||||
files. Unlike the input and output functions (@pxref{I/O on Streams};
|
||||
@pxref{Low-Level I/O}), these functions are concerned with operating
|
||||
on the files themselves rather than on their contents.
|
||||
@ -63,7 +63,7 @@ the current working directory, storing it in the character array
|
||||
@var{buffer} that you provide. The @var{size} argument is how you tell
|
||||
the system the allocation size of @var{buffer}.
|
||||
|
||||
The GNU library version of this function also permits you to specify a
|
||||
The @glibcadj{} version of this function also permits you to specify a
|
||||
null pointer for the @var{buffer} argument. Then @code{getcwd}
|
||||
allocates a buffer automatically, as with @code{malloc}
|
||||
(@pxref{Unconstrained Allocation}). If the @var{size} is greater than
|
||||
@ -117,7 +117,7 @@ software.
|
||||
@comment BSD
|
||||
@deftypefn {Deprecated Function} {char *} getwd (char *@var{buffer})
|
||||
This is similar to @code{getcwd}, but has no way to specify the size of
|
||||
the buffer. The GNU library provides @code{getwd} only
|
||||
the buffer. @Theglibc{} provides @code{getwd} only
|
||||
for backwards compatibility with BSD.
|
||||
|
||||
The @var{buffer} argument should be a pointer to an array at least
|
||||
@ -413,7 +413,7 @@ descriptor which is created by the @code{opendir} call. For instance,
|
||||
to switch the current working directory to the directory just read the
|
||||
@code{fchdir} function could be used. Historically the @code{DIR} type
|
||||
was exposed and programs could access the fields. This does not happen
|
||||
in the GNU C library. Instead a separate function is provided to allow
|
||||
in @theglibc{}. Instead a separate function is provided to allow
|
||||
access.
|
||||
|
||||
@comment dirent.h
|
||||
@ -634,7 +634,7 @@ the global variable @code{errno} contains more information on the error.
|
||||
|
||||
As described above the fourth argument to the @code{scandir} function
|
||||
must be a pointer to a sorting function. For the convenience of the
|
||||
programmer the GNU C library contains implementations of functions which
|
||||
programmer @theglibc{} contains implementations of functions which
|
||||
are very helpful for this purpose.
|
||||
|
||||
@comment dirent.h
|
||||
@ -3035,7 +3035,7 @@ set the real size of the file.
|
||||
@cindex special files
|
||||
|
||||
The @code{mknod} function is the primitive for making special files,
|
||||
such as files that correspond to devices. The GNU library includes
|
||||
such as files that correspond to devices. @Theglibc{} includes
|
||||
this function for compatibility with BSD.
|
||||
|
||||
The prototype for @code{mknod} is declared in @file{sys/stat.h}.
|
||||
@ -3176,7 +3176,7 @@ you can create with @code{tmpnam}. You can rely on being able to call
|
||||
@code{tmpnam} at least this many times before it might fail saying you
|
||||
have made too many temporary file names.
|
||||
|
||||
With the GNU library, you can create a very large number of temporary
|
||||
With @theglibc{}, you can create a very large number of temporary
|
||||
file names. If you actually created the files, you would probably run
|
||||
out of disk space before you ran out of names. Some other systems have
|
||||
a fixed, small limit on the number of temporary files. The limit is
|
||||
|
@ -3,7 +3,7 @@
|
||||
@appendix Summary of Library Facilities
|
||||
|
||||
This appendix is a complete list of the facilities declared within the
|
||||
header files supplied with the GNU C library. Each entry also lists the
|
||||
header files supplied with @theglibc{}. Each entry also lists the
|
||||
standard or other source from which each facility is derived, and tells
|
||||
you where in the manual you can find more information about how to use
|
||||
it.
|
||||
|
@ -1,17 +1,18 @@
|
||||
@c This is for making the `INSTALL' file for the distribution.
|
||||
@c Makeinfo ignores it when processing the file from the include.
|
||||
@setfilename INSTALL
|
||||
@include macros.texi
|
||||
|
||||
@node Installation, Maintenance, Library Summary, Top
|
||||
@c %MENU% How to install the GNU C library
|
||||
@appendix Installing the GNU C Library
|
||||
@c %MENU% How to install the GNU C Library
|
||||
@appendix Installing @theglibc{}
|
||||
|
||||
Before you do anything else, you should read the file @file{FAQ} located
|
||||
at the top level of the source tree. This file answers common questions
|
||||
and describes problems you may experience with compilation and
|
||||
installation. It is updated more frequently than this manual.
|
||||
|
||||
Features can be added to GNU Libc via @dfn{add-on} bundles. These are
|
||||
Features can be added to @theglibc{} via @dfn{add-on} bundles. These are
|
||||
separate tar files, which you unpack into the top level of the source
|
||||
tree. Then you give @code{configure} the @samp{--enable-add-ons} option
|
||||
to activate them, and they will be compiled into the library.
|
||||
@ -29,13 +30,14 @@ GNU Make, and possibly others. @xref{Tools for Compilation}, below.
|
||||
@end menu
|
||||
|
||||
@node Configuring and compiling
|
||||
@appendixsec Configuring and compiling GNU Libc
|
||||
@appendixsec Configuring and compiling @theglibc{}
|
||||
@cindex configuring
|
||||
@cindex compiling
|
||||
|
||||
GNU libc cannot be compiled in the source directory. You must build
|
||||
@Theglibc{} cannot be compiled in the source directory. You must build
|
||||
it in a separate build directory. For example, if you have unpacked
|
||||
the glibc sources in @file{/src/gnu/glibc-@var{version}}, create a directory
|
||||
the @glibcadj{} sources in @file{/src/gnu/glibc-@var{version}},
|
||||
create a directory
|
||||
@file{/src/gnu/glibc-build} to put the object files in. This allows
|
||||
removing the whole build directory in case an error occurs, which is
|
||||
the safest way to get a fresh start and should always be done.
|
||||
@ -54,7 +56,7 @@ directory, especially some files in the manual subdirectory.
|
||||
@noindent
|
||||
@code{configure} takes many options, but the only one that is usually
|
||||
mandatory is @samp{--prefix}. This option tells @code{configure}
|
||||
where you want glibc installed. This defaults to @file{/usr/local},
|
||||
where you want @theglibc{} installed. This defaults to @file{/usr/local},
|
||||
but the normal setting to install as the standard system library is
|
||||
@samp{--prefix=/usr} for GNU/Linux systems and @samp{--prefix=} (an
|
||||
empty prefix) for GNU/Hurd systems.
|
||||
@ -79,15 +81,15 @@ directory if that option is specified, or @file{/usr/local} otherwise.
|
||||
|
||||
@item --with-headers=@var{directory}
|
||||
Look for kernel header files in @var{directory}, not
|
||||
@file{/usr/include}. Glibc needs information from the kernel's header
|
||||
files describing the interface to the kernel. Glibc will normally
|
||||
@file{/usr/include}. @Theglibc{} needs information from the kernel's header
|
||||
files describing the interface to the kernel. @Theglibc{} will normally
|
||||
look in @file{/usr/include} for them,
|
||||
but if you specify this option, it will look in @var{DIRECTORY} instead.
|
||||
|
||||
This option is primarily of use on a system where the headers in
|
||||
@file{/usr/include} come from an older version of glibc. Conflicts can
|
||||
@file{/usr/include} come from an older version of @theglibc{}. Conflicts can
|
||||
occasionally happen in this case. You can also use this option if you want to
|
||||
compile glibc with a newer set of kernel headers than the ones found in
|
||||
compile @theglibc{} with a newer set of kernel headers than the ones found in
|
||||
@file{/usr/include}.
|
||||
|
||||
@item --enable-add-ons[=@var{list}]
|
||||
@ -112,7 +114,7 @@ compatibility code is added, and the faster the code gets.
|
||||
Use the binutils (assembler and linker) in @file{@var{directory}}, not
|
||||
the ones the C compiler would default to. You can use this option if
|
||||
the default binutils on your system cannot deal with all the constructs
|
||||
in the GNU C library. In that case, @code{configure} will detect the
|
||||
in @theglibc{}. In that case, @code{configure} will detect the
|
||||
problem and suppress these constructs, so that the library will still be
|
||||
usable, but functionality may be lost---for example, you can't build a
|
||||
shared libc with old binutils.
|
||||
@ -156,7 +158,7 @@ compatibility problems.
|
||||
@itemx --host=@var{host-system}
|
||||
These options are for cross-compiling. If you specify both options and
|
||||
@var{build-system} is different from @var{host-system}, @code{configure}
|
||||
will prepare to cross-compile glibc from @var{build-system} to be used
|
||||
will prepare to cross-compile @theglibc{} from @var{build-system} to be used
|
||||
on @var{host-system}. You'll probably need the @samp{--with-headers}
|
||||
option too, and you may have to override @var{configure}'s selection of
|
||||
the compiler and/or binutils.
|
||||
@ -193,7 +195,7 @@ successfully, do not use the built library, and report a bug after
|
||||
verifying that the problem is not already known. @xref{Reporting Bugs},
|
||||
for instructions on reporting bugs. Note that some of the tests assume
|
||||
they are not being run by @code{root}. We recommend you compile and
|
||||
test glibc as an unprivileged user.
|
||||
test @theglibc{} as an unprivileged user.
|
||||
|
||||
Before reporting bugs make sure there is no problem with your system.
|
||||
The tests (and later installation) use some pre-existing files of the
|
||||
@ -213,7 +215,7 @@ the file @file{configparms}. To change them, create a
|
||||
for your system. The file is included and parsed by @code{make} and has
|
||||
to follow the conventions for makefiles.
|
||||
|
||||
It is easy to configure the GNU C library for cross-compilation by
|
||||
It is easy to configure @theglibc{} for cross-compilation by
|
||||
setting a few variables in @file{configparms}. Set @code{CC} to the
|
||||
cross-compiler for the target you configured the library for; it is
|
||||
important to use this same @code{CC} value when running
|
||||
@ -232,13 +234,14 @@ object files for the target you configured for.
|
||||
To install the library and its header files, and the Info files of the
|
||||
manual, type @code{env LANGUAGE=C LC_ALL=C make install}. This will
|
||||
build things, if necessary, before installing them; however, you should
|
||||
still compile everything first. If you are installing glibc as your
|
||||
still compile everything first. If you are installing @theglibc{} as your
|
||||
primary C library, we recommend that you shut the system down to
|
||||
single-user mode first, and reboot afterward. This minimizes the risk
|
||||
of breaking things when the library changes out from underneath.
|
||||
|
||||
@samp{make install} will do the entire job of upgrading from a
|
||||
previous installation of glibc 2.x. There may sometimes be headers
|
||||
previous installation of @theglibc{} version 2.x. There may sometimes
|
||||
be headers
|
||||
left behind from the previous installation, but those are generally
|
||||
harmless. If you want to avoid leaving headers behind you can do
|
||||
things in the following order.
|
||||
@ -252,17 +255,17 @@ library requires the ability to compile and run programs against the old
|
||||
library. The new @file{/usr/include}, after switching the include
|
||||
directories and before installing the library should contain the Linux
|
||||
headers, but nothing else. If you do this, you will need to restore
|
||||
any headers from non-glibc libraries youself after installing the
|
||||
any headers from libraries other than @theglibc{} yourself after installing the
|
||||
library.
|
||||
|
||||
You can install glibc somewhere other than where you configured it to go
|
||||
You can install @theglibc{} somewhere other than where you configured it to go
|
||||
by setting the @code{install_root} variable on the command line for
|
||||
@samp{make install}. The value of this variable is prepended to all the
|
||||
paths for installation. This is useful when setting up a chroot
|
||||
environment or preparing a binary distribution. The directory should be
|
||||
specified with an absolute file name.
|
||||
|
||||
Glibc includes a daemon called @code{nscd}, which you
|
||||
@Theglibc{} includes a daemon called @code{nscd}, which you
|
||||
may or may not want to run. @code{nscd} caches name service lookups; it
|
||||
can dramatically improve performance with NIS+, and may help with DNS as
|
||||
well.
|
||||
@ -278,11 +281,11 @@ providing pty slaves, you don't need this program; otherwise you do.
|
||||
The source for @file{pt_chown} is in @file{login/programs/pt_chown.c}.
|
||||
|
||||
After installation you might want to configure the timezone and locale
|
||||
installation of your system. The GNU C library comes with a locale
|
||||
installation of your system. @Theglibc{} comes with a locale
|
||||
database which gets configured with @code{localedef}. For example, to
|
||||
set up a German locale with name @code{de_DE}, simply issue the command
|
||||
@samp{localedef -i de_DE -f ISO-8859-1 de_DE}. To configure all locales
|
||||
that are supported by glibc, you can issue from your build directory the
|
||||
that are supported by @theglibc{}, you can issue from your build directory the
|
||||
command @samp{make localedata/install-locales}.
|
||||
|
||||
To configure the locally used timezone, set the @code{TZ} environment
|
||||
@ -300,14 +303,14 @@ timezone file which is in @file{/usr/share/zoneinfo} to the file
|
||||
@cindex tools, for installing library
|
||||
|
||||
We recommend installing the following GNU tools before attempting to
|
||||
build the GNU C library:
|
||||
build @theglibc{}:
|
||||
|
||||
@itemize @bullet
|
||||
@item
|
||||
GNU @code{make} 3.79 or newer
|
||||
|
||||
You need the latest version of GNU @code{make}. Modifying the GNU C
|
||||
Library to work with other @code{make} programs would be so difficult that
|
||||
You need the latest version of GNU @code{make}. Modifying @theglibc{}
|
||||
to work with other @code{make} programs would be so difficult that
|
||||
we recommend you port GNU @code{make} instead. @strong{Really.} We
|
||||
recommend GNU @code{make} version 3.79. All earlier versions have severe
|
||||
bugs or lack features.
|
||||
@ -316,17 +319,17 @@ bugs or lack features.
|
||||
GCC 4.3 or newer, GCC 4.6 recommended
|
||||
|
||||
GCC 4.3 or higher is required; as of this writing, GCC 4.6 is the
|
||||
compiler we advise to use to build the GNU C library.
|
||||
compiler we advise to use to build @theglibc{}.
|
||||
|
||||
You can use whatever compiler you like to compile programs that use GNU
|
||||
libc.
|
||||
You can use whatever compiler you like to compile programs that use
|
||||
@theglibc{}.
|
||||
|
||||
Check the FAQ for any special compiler issues on particular platforms.
|
||||
|
||||
@item
|
||||
GNU @code{binutils} 2.15 or later
|
||||
|
||||
You must use GNU @code{binutils} (as and ld) to build the GNU C library.
|
||||
You must use GNU @code{binutils} (as and ld) to build @theglibc{}.
|
||||
No other assembler or linker has the necessary functionality at the
|
||||
moment.
|
||||
|
||||
@ -386,41 +389,41 @@ patches, although we try to avoid this.
|
||||
@appendixsec Specific advice for GNU/Linux systems
|
||||
@cindex kernel header files
|
||||
|
||||
If you are installing GNU libc on a GNU/Linux system, you need to have
|
||||
If you are installing @theglibc{} on a GNU/Linux system, you need to have
|
||||
the header files from a 2.6.19.1 or newer kernel around for reference.
|
||||
These headers must be installed using @samp{make headers_install}; the
|
||||
headers present in the kernel source directory are not suitable for
|
||||
direct use by GNU libc. You do not need to use that kernel, just have
|
||||
its headers installed where glibc can access them, referred to here as
|
||||
direct use by @theglibc{}. You do not need to use that kernel, just have
|
||||
its headers installed where @theglibc{} can access them, referred to here as
|
||||
@var{install-directory}. The easiest way to do this is to unpack it
|
||||
in a directory such as @file{/usr/src/linux-@var{version}}. In that
|
||||
directory, run @samp{make headers_install
|
||||
INSTALL_HDR_PATH=@var{install-directory}}. Finally, configure glibc
|
||||
INSTALL_HDR_PATH=@var{install-directory}}. Finally, configure @theglibc{}
|
||||
with the option @samp{--with-headers=@var{install-directory}/include}.
|
||||
Use the most recent kernel you can get your hands on. (If you are
|
||||
cross-compiling GNU libc, you need to specify
|
||||
cross-compiling @theglibc{}, you need to specify
|
||||
@samp{ARCH=@var{architecture}} in the @samp{make headers_install}
|
||||
command, where @var{architecture} is the architecture name used by the
|
||||
Linux kernel, such as @samp{x86} or @samp{powerpc}.)
|
||||
|
||||
After installing GNU libc, you may need to remove or rename
|
||||
After installing @theglibc{}, you may need to remove or rename
|
||||
directories such as @file{/usr/include/linux} and
|
||||
@file{/usr/include/asm}, and replace them with copies of directories
|
||||
such as @file{linux} and @file{asm} from
|
||||
@file{@var{install-directory}/include}. All directories present in
|
||||
@file{@var{install-directory}/include} should be copied, except that
|
||||
GNU libc provides its own version of @file{/usr/include/scsi}; the
|
||||
@theglibc{} provides its own version of @file{/usr/include/scsi}; the
|
||||
files provided by the kernel should be copied without replacing those
|
||||
provided by GNU libc. The @file{linux}, @file{asm} and
|
||||
provided by @theglibc{}. The @file{linux}, @file{asm} and
|
||||
@file{asm-generic} directories are required to compile programs using
|
||||
GNU libc; the other directories describe interfaces to the kernel but
|
||||
@theglibc{}; the other directories describe interfaces to the kernel but
|
||||
are not required if not compiling programs using those interfaces.
|
||||
You do not need to copy kernel headers if you did not specify an
|
||||
alternate kernel header source using @samp{--with-headers}.
|
||||
|
||||
GNU/Linux expects some components of the libc installation to be in
|
||||
GNU/Linux expects some components of the @glibcadj{} installation to be in
|
||||
@file{/lib} and some in @file{/usr/lib}. This is handled automatically
|
||||
if you configure glibc with @samp{--prefix=/usr}. If you set some other
|
||||
if you configure @theglibc{} with @samp{--prefix=/usr}. If you set some other
|
||||
prefix or allow it to default to @file{/usr/local}, then all the
|
||||
components are installed there.
|
||||
|
||||
@ -434,7 +437,7 @@ program.
|
||||
@cindex reporting bugs
|
||||
@cindex bugs, reporting
|
||||
|
||||
There are probably bugs in the GNU C library. There are certainly
|
||||
There are probably bugs in @theglibc{}. There are certainly
|
||||
errors and omissions in this manual. If you report them, they will get
|
||||
fixed. If you don't, no one will ever know about them and they will
|
||||
remain unfixed for all eternity, if not longer.
|
||||
@ -449,14 +452,14 @@ normally includes a patch or a hint on solving the problem.
|
||||
|
||||
To report a bug, first you must find it. With any luck, this will be the
|
||||
hard part. Once you've found a bug, make sure it's really a bug. A
|
||||
good way to do this is to see if the GNU C library behaves the same way
|
||||
good way to do this is to see if @theglibc{} behaves the same way
|
||||
some other C library does. If so, probably you are wrong and the
|
||||
libraries are right (but not necessarily). If not, one of the libraries
|
||||
is probably wrong. It might not be the GNU library. Many historical
|
||||
is probably wrong. It might not be @theglibc{}. Many historical
|
||||
Unix C libraries permit things that we don't, such as closing a file
|
||||
twice.
|
||||
|
||||
If you think you have found some way in which the GNU C library does not
|
||||
If you think you have found some way in which @theglibc{} does not
|
||||
conform to the ISO and POSIX standards (@pxref{Standards and
|
||||
Portability}), that is definitely a bug. Report it!
|
||||
|
||||
|
@ -9,13 +9,13 @@ in a standard @dfn{library}, which you compile and link with your
|
||||
programs.
|
||||
@cindex library
|
||||
|
||||
The GNU C library, described in this document, defines all of the
|
||||
@Theglibc{}, described in this document, defines all of the
|
||||
library functions that are specified by the @w{ISO C} standard, as well as
|
||||
additional features specific to POSIX and other derivatives of the Unix
|
||||
operating system, and extensions specific to the GNU system.
|
||||
|
||||
The purpose of this manual is to tell you how to use the facilities
|
||||
of the GNU library. We have mentioned which features belong to which
|
||||
of @theglibc{}. We have mentioned which features belong to which
|
||||
standards to help you identify things that are potentially non-portable
|
||||
to other systems. But the emphasis in this manual is not on strict
|
||||
portability.
|
||||
@ -38,7 +38,7 @@ concepts. Specifically, familiarity with ISO standard C
|
||||
(@pxref{ISO C}), rather than ``traditional'' pre-ISO C dialects, is
|
||||
assumed.
|
||||
|
||||
The GNU C library includes several @dfn{header files}, each of which
|
||||
@Theglibc{} includes several @dfn{header files}, each of which
|
||||
provides definitions and declarations for a group of related facilities;
|
||||
this information is used by the C compiler when processing your program.
|
||||
For example, the header file @file{stdio.h} declares facilities for
|
||||
@ -48,7 +48,7 @@ generally follows the same division as the header files.
|
||||
|
||||
If you are reading this manual for the first time, you should read all
|
||||
of the introductory material and skim the remaining chapters. There are
|
||||
a @emph{lot} of functions in the GNU C library and it's not realistic to
|
||||
a @emph{lot} of functions in @theglibc{} and it's not realistic to
|
||||
expect that you will be able to remember exactly @emph{how} to use each
|
||||
and every one of them. It's more important to become generally familiar
|
||||
with the kinds of facilities that the library provides, so that when you
|
||||
@ -61,12 +61,12 @@ specific information about them.
|
||||
@section Standards and Portability
|
||||
@cindex standards
|
||||
|
||||
This section discusses the various standards and other sources that the
|
||||
GNU C library is based upon. These sources include the @w{ISO C} and
|
||||
This section discusses the various standards and other sources that @theglibc{}
|
||||
is based upon. These sources include the @w{ISO C} and
|
||||
POSIX standards, and the System V and Berkeley Unix implementations.
|
||||
|
||||
The primary focus of this manual is to tell you how to make effective
|
||||
use of the GNU library facilities. But if you are concerned about
|
||||
use of the @glibcadj{} facilities. But if you are concerned about
|
||||
making your programs compatible with these standards, or portable to
|
||||
operating systems other than GNU, this can affect how you use the
|
||||
library. This section gives you an overview of these standards, so that
|
||||
@ -91,14 +91,14 @@ standards each function or symbol comes from.
|
||||
@subsection ISO C
|
||||
@cindex ISO C
|
||||
|
||||
The GNU C library is compatible with the C standard adopted by the
|
||||
@Theglibc{} is compatible with the C standard adopted by the
|
||||
American National Standards Institute (ANSI):
|
||||
@cite{American National Standard X3.159-1989---``ANSI C''} and later
|
||||
by the International Standardization Organization (ISO):
|
||||
@cite{ISO/IEC 9899:1990, ``Programming languages---C''}.
|
||||
We here refer to the standard as @w{ISO C} since this is the more
|
||||
general standard in respect of ratification.
|
||||
The header files and library facilities that make up the GNU library are
|
||||
The header files and library facilities that make up @theglibc{} are
|
||||
a superset of those specified by the @w{ISO C} standard.@refill
|
||||
|
||||
@pindex gcc
|
||||
@ -131,7 +131,7 @@ not aim for completeness.
|
||||
@cindex IEEE Std 1003.2
|
||||
@cindex ISO/IEC 9945-2
|
||||
|
||||
The GNU library is also compatible with the ISO @dfn{POSIX} family of
|
||||
@Theglibc{} is also compatible with the ISO @dfn{POSIX} family of
|
||||
standards, known more formally as the @dfn{Portable Operating System
|
||||
Interface for Computer Environments} (ISO/IEC 9945). They were also
|
||||
published as ANSI/IEEE Std 1003. POSIX is derived mostly from various
|
||||
@ -146,7 +146,7 @@ particular kind of operating system environment, rather than general
|
||||
programming language support which can run in many diverse operating
|
||||
system environments.@refill
|
||||
|
||||
The GNU C library implements all of the functions specified in
|
||||
@Theglibc{} implements all of the functions specified in
|
||||
@cite{ISO/IEC 9945-1:1996, the POSIX System Application Program
|
||||
Interface}, commonly referred to as POSIX.1. The primary extensions to
|
||||
the @w{ISO C} facilities specified by this standard include file system
|
||||
@ -155,7 +155,7 @@ terminal control functions (@pxref{Low-Level Terminal Interface}), and
|
||||
process control functions (@pxref{Processes}).
|
||||
|
||||
Some facilities from @cite{ISO/IEC 9945-2:1993, the POSIX Shell and
|
||||
Utilities standard} (POSIX.2) are also implemented in the GNU library.
|
||||
Utilities standard} (POSIX.2) are also implemented in @theglibc{}.
|
||||
These include utilities for dealing with regular expressions and other
|
||||
pattern matching facilities (@pxref{Pattern Matching}).
|
||||
|
||||
@ -181,7 +181,7 @@ pattern matching facilities (@pxref{Pattern Matching}).
|
||||
@cindex SunOS
|
||||
@cindex Unix, Berkeley
|
||||
|
||||
The GNU C library defines facilities from some versions of Unix which
|
||||
@Theglibc{} defines facilities from some versions of Unix which
|
||||
are not formally standardized, specifically from the 4.2 BSD, 4.3 BSD,
|
||||
and 4.4 BSD Unix systems (also known as @dfn{Berkeley Unix}) and from
|
||||
@dfn{SunOS} (a popular 4.2 BSD derivative that includes some Unix System
|
||||
@ -202,7 +202,7 @@ The @dfn{System V Interface Description} (SVID) is a document describing
|
||||
the AT&T Unix System V operating system. It is to some extent a
|
||||
superset of the POSIX standard (@pxref{POSIX}).
|
||||
|
||||
The GNU C library defines most of the facilities required by the SVID
|
||||
@Theglibc{} defines most of the facilities required by the SVID
|
||||
that are not also required by the @w{ISO C} or POSIX standards, for
|
||||
compatibility with System V Unix and other Unix systems (such as
|
||||
SunOS) which include these facilities. However, many of the more
|
||||
@ -222,7 +222,7 @@ a more general standard than POSIX. X/Open owns the Unix copyright and
|
||||
the XPG specifies the requirements for systems which are intended to be
|
||||
a Unix system.
|
||||
|
||||
The GNU C library complies to the X/Open Portability Guide, Issue 4.2,
|
||||
@Theglibc{} complies to the X/Open Portability Guide, Issue 4.2,
|
||||
with all extensions common to XSI (X/Open System Interface)
|
||||
compliant systems and also all X/Open UNIX extensions.
|
||||
|
||||
@ -238,7 +238,7 @@ functionality is available on commercial systems.
|
||||
@section Using the Library
|
||||
|
||||
This section describes some of the practical issues involved in using
|
||||
the GNU C library.
|
||||
@theglibc{}.
|
||||
|
||||
@menu
|
||||
* Header Files:: How to include the header files in your
|
||||
@ -269,7 +269,7 @@ variable or says what a function does.)
|
||||
@cindex definition (compared to declaration)
|
||||
@cindex declaration (compared to definition)
|
||||
|
||||
In order to use the facilities in the GNU C library, you should be sure
|
||||
In order to use the facilities in @theglibc{}, you should be sure
|
||||
that your program source files include the appropriate header files.
|
||||
This is so that the compiler has declarations of these facilities
|
||||
available and can correctly process references to them. Once your
|
||||
@ -310,7 +310,7 @@ For more information about the use of header files and @samp{#include}
|
||||
directives, @pxref{Header Files,,, cpp.info, The GNU C Preprocessor
|
||||
Manual}.@refill
|
||||
|
||||
The GNU C library provides several header files, each of which contains
|
||||
@Theglibc{} provides several header files, each of which contains
|
||||
the type and macro definitions and variable and function declarations
|
||||
for a group of related facilities. This means that your programs may
|
||||
need to include several header files, depending on exactly which
|
||||
@ -319,8 +319,8 @@ facilities you are using.
|
||||
Some library header files include other library header files
|
||||
automatically. However, as a matter of programming style, you should
|
||||
not rely on this; it is better to explicitly include all the header
|
||||
files required for the library facilities you are using. The GNU C
|
||||
library header files have been written in such a way that it doesn't
|
||||
files required for the library facilities you are using. The @glibcadj{}
|
||||
header files have been written in such a way that it doesn't
|
||||
matter if a header file is accidentally included more than once;
|
||||
including a header file a second time has no effect. Likewise, if your
|
||||
program needs to include multiple header files, the order in which they
|
||||
@ -572,7 +572,7 @@ debugging mechanism which allows you to put assertions in your code, and
|
||||
have diagnostic messages printed if the tests fail.
|
||||
|
||||
@item
|
||||
@ref{Memory}, describes the GNU library's facilities for managing and
|
||||
@ref{Memory}, describes @theglibc{}'s facilities for managing and
|
||||
using virtual and real memory, including dynamic allocation of virtual
|
||||
memory. If you do not know in advance how much memory your program
|
||||
needs, you can allocate it dynamically instead, and manipulate it via
|
||||
@ -714,7 +714,7 @@ macros in the library, with complete data types and function prototypes,
|
||||
and says what standard or system each is derived from.
|
||||
|
||||
@item
|
||||
@ref{Installation}, explains how to build and install the GNU C library on
|
||||
@ref{Installation}, explains how to build and install @theglibc{} on
|
||||
your system, and how to report any bugs you might find.
|
||||
|
||||
@item
|
||||
|
@ -3,8 +3,8 @@
|
||||
@chapter Input/Output Overview
|
||||
|
||||
Most programs need to do either input (reading data) or output (writing
|
||||
data), or most frequently both, in order to do anything useful. The GNU
|
||||
C library provides such a large selection of input and output functions
|
||||
data), or most frequently both, in order to do anything useful. @Theglibc{}
|
||||
provides such a large selection of input and output functions
|
||||
that the hardest part is often deciding which function is most
|
||||
appropriate!
|
||||
|
||||
@ -65,7 +65,7 @@ closed a stream or file descriptor, you cannot do any more input or
|
||||
output operations on it.
|
||||
|
||||
@menu
|
||||
* Streams and File Descriptors:: The GNU Library provides two ways
|
||||
* Streams and File Descriptors:: The GNU C Library provides two ways
|
||||
to access the contents of files.
|
||||
* File Position:: The number of bytes from the
|
||||
beginning of the file.
|
||||
@ -123,8 +123,8 @@ than GNU, you should also be aware that file descriptors are not as
|
||||
portable as streams. You can expect any system running @w{ISO C} to
|
||||
support streams, but non-GNU systems may not support file descriptors at
|
||||
all, or may only implement a subset of the GNU functions that operate on
|
||||
file descriptors. Most of the file descriptor functions in the GNU
|
||||
library are included in the POSIX.1 standard, however.
|
||||
file descriptors. Most of the file descriptor functions in @theglibc{}
|
||||
are included in the POSIX.1 standard, however.
|
||||
|
||||
@node File Position, , Streams and File Descriptors, I/O Concepts
|
||||
@subsection File Position
|
||||
@ -236,7 +236,7 @@ in @ref{File System Interface}.
|
||||
@subsection File Name Resolution
|
||||
|
||||
A file name consists of file name components separated by slash
|
||||
(@samp{/}) characters. On the systems that the GNU C library supports,
|
||||
(@samp{/}) characters. On the systems that @theglibc{} supports,
|
||||
multiple successive @samp{/} characters are equivalent to a single
|
||||
@samp{/} character.
|
||||
|
||||
|
@ -107,7 +107,7 @@ controlling terminal,
|
||||
@cindex job control is optional
|
||||
|
||||
Not all operating systems support job control. The GNU system does
|
||||
support job control, but if you are using the GNU library on some other
|
||||
support job control, but if you are using @theglibc{} on some other
|
||||
system, that system may not support job control itself.
|
||||
|
||||
You can use the @code{_POSIX_JOB_CONTROL} macro to test at compile-time
|
||||
@ -1026,7 +1026,7 @@ to job control.
|
||||
@cindex controlling terminal, determining
|
||||
|
||||
You can use the @code{ctermid} function to get a file name that you can
|
||||
use to open the controlling terminal. In the GNU library, it returns
|
||||
use to open the controlling terminal. In @theglibc{}, it returns
|
||||
the same string all the time: @code{"/dev/tty"}. That is a special
|
||||
``magic'' file name that refers to the controlling terminal of the
|
||||
current process (if it has one). To find the name of the specific
|
||||
|
@ -454,7 +454,7 @@ This ends the use of @var{ap}. After a @code{va_end} call, further
|
||||
@code{va_end} before returning from the function in which @code{va_start}
|
||||
was invoked with the same @var{ap} argument.
|
||||
|
||||
In the GNU C library, @code{va_end} does nothing, and you need not ever
|
||||
In @theglibc{}, @code{va_end} does nothing, and you need not ever
|
||||
use it except for reasons of portability.
|
||||
@refill
|
||||
@end deftypefn
|
||||
@ -776,7 +776,7 @@ It's equal to @code{SCHAR_MAX} if @code{char} is signed, or
|
||||
@item SHRT_MIN
|
||||
|
||||
This is the minimum value that can be represented by a @w{@code{signed
|
||||
short int}}. On most machines that the GNU C library runs on,
|
||||
short int}}. On most machines that @theglibc{} runs on,
|
||||
@code{short} integers are 16-bit quantities.
|
||||
|
||||
@comment limits.h
|
||||
@ -795,7 +795,7 @@ respectively.
|
||||
@item INT_MIN
|
||||
|
||||
This is the minimum value that can be represented by a @w{@code{signed
|
||||
int}}. On most machines that the GNU C system runs on, an @code{int} is
|
||||
int}}. On most machines that @theglibc{} runs on, an @code{int} is
|
||||
a 32-bit quantity.
|
||||
|
||||
@comment limits.h
|
||||
@ -813,7 +813,7 @@ the type @w{@code{signed int}} and the type @w{@code{unsigned int}}.
|
||||
@item LONG_MIN
|
||||
|
||||
This is the minimum value that can be represented by a @w{@code{signed
|
||||
long int}}. On most machines that the GNU C system runs on, @code{long}
|
||||
long int}}. On most machines that @theglibc{} runs on, @code{long}
|
||||
integers are 32-bit quantities, the same size as @code{int}.
|
||||
|
||||
@comment limits.h
|
||||
@ -831,7 +831,7 @@ These are the maximum values that can be represented by a
|
||||
@item LLONG_MIN
|
||||
|
||||
This is the minimum value that can be represented by a @w{@code{signed
|
||||
long long int}}. On most machines that the GNU C system runs on,
|
||||
long long int}}. On most machines that @theglibc{} runs on,
|
||||
@w{@code{long long}} integers are 64-bit quantities.
|
||||
|
||||
@comment limits.h
|
||||
@ -939,8 +939,8 @@ Sometimes, in the actual bits representing the floating point number,
|
||||
the exponent is @dfn{biased} by adding a constant to it, to make it
|
||||
always be represented as an unsigned quantity. This is only important
|
||||
if you have some reason to pick apart the bit fields making up the
|
||||
floating point number by hand, which is something for which the GNU
|
||||
library provides no support. So this is ignored in the discussion that
|
||||
floating point number by hand, which is something for which @theglibc{}
|
||||
provides no support. So this is ignored in the discussion that
|
||||
follows.
|
||||
|
||||
@item
|
||||
@ -961,7 +961,7 @@ the mantissa. This is a bit which is present virtually in the mantissa,
|
||||
but not stored in memory because its value is always 1 in a normalized
|
||||
number. The precision figure (see above) includes any hidden bits.
|
||||
|
||||
Again, the GNU library provides no facilities for dealing with such
|
||||
Again, @theglibc{} provides no facilities for dealing with such
|
||||
low-level aspects of the representation.
|
||||
@end itemize
|
||||
|
||||
|
@ -4,6 +4,8 @@
|
||||
@settitle The GNU C Library
|
||||
@c setchapternewpage odd
|
||||
|
||||
@include macros.texi
|
||||
|
||||
@comment Tell install-info what to do.
|
||||
@dircategory Software libraries
|
||||
@direntry
|
||||
@ -29,7 +31,7 @@
|
||||
@set FDL_VERSION 1.3
|
||||
|
||||
@copying
|
||||
This file documents the GNU C library.
|
||||
This file documents @theglibc{}.
|
||||
|
||||
This is
|
||||
@c Disabled (printed editions, see above).
|
||||
@ -94,7 +96,7 @@ This is
|
||||
@c Disabled (printed editions, see above).
|
||||
@c Edition @value{EDITION} of
|
||||
@cite{The GNU C Library Reference Manual}, for Version @value{VERSION}
|
||||
of the GNU C Library.
|
||||
of @theglibc{}.
|
||||
@end ifnottex
|
||||
|
||||
@include top-menu.texi
|
||||
|
@ -332,7 +332,7 @@ some input. But if the @code{O_NONBLOCK} flag is set for the file
|
||||
reading any data, and reports this error.
|
||||
|
||||
@strong{Compatibility Note:} Most versions of BSD Unix use a different
|
||||
error code for this: @code{EWOULDBLOCK}. In the GNU library,
|
||||
error code for this: @code{EWOULDBLOCK}. In @theglibc{},
|
||||
@code{EWOULDBLOCK} is an alias for @code{EAGAIN}, so it doesn't matter
|
||||
which name you use.
|
||||
|
||||
@ -483,7 +483,7 @@ flow control, where output has been suspended by receipt of a STOP
|
||||
character.
|
||||
|
||||
@strong{Compatibility Note:} Most versions of BSD Unix use a different
|
||||
error code for this: @code{EWOULDBLOCK}. In the GNU library,
|
||||
error code for this: @code{EWOULDBLOCK}. In @theglibc{},
|
||||
@code{EWOULDBLOCK} is an alias for @code{EAGAIN}, so it doesn't matter
|
||||
which name you use.
|
||||
|
||||
@ -844,7 +844,7 @@ null pointer is returned instead.
|
||||
|
||||
In some other systems, @code{fdopen} may fail to detect that the modes
|
||||
for file descriptor do not permit the access specified by
|
||||
@code{opentype}. The GNU C library always checks for this.
|
||||
@code{opentype}. @Theglibc{} always checks for this.
|
||||
@end deftypefun
|
||||
|
||||
For an example showing the use of the @code{fdopen} function,
|
||||
@ -1043,8 +1043,8 @@ with multiple calls to @code{read} and @code{write}, it is inefficient
|
||||
because there is overhead associated with each kernel call.
|
||||
|
||||
Instead, many platforms provide special high-speed primitives to perform
|
||||
these @dfn{scatter-gather} operations in a single kernel call. The GNU C
|
||||
library will provide an emulation on any system that lacks these
|
||||
these @dfn{scatter-gather} operations in a single kernel call. @Theglibc{}
|
||||
will provide an emulation on any system that lacks these
|
||||
primitives, so they are not a portability threat. They are defined in
|
||||
@code{sys/uio.h}.
|
||||
|
||||
@ -1216,7 +1216,7 @@ systems. They are also useful to share data between multiple tasks
|
||||
without creating a file.
|
||||
|
||||
On some systems using private anonymous mmaps is more efficient than using
|
||||
@code{malloc} for large blocks. This is not an issue with the GNU C library,
|
||||
@code{malloc} for large blocks. This is not an issue with @theglibc{},
|
||||
as the included @code{malloc} automatically uses @code{mmap} where appropriate.
|
||||
|
||||
@c Linux has some other MAP_ options, which I have not discussed here.
|
||||
@ -2498,7 +2498,7 @@ At the point of this writing, the available implementation is a userlevel
|
||||
implementation which uses threads for handling the enqueued requests.
|
||||
While this implementation requires making some decisions about
|
||||
limitations, hard limitations are something which is best avoided
|
||||
in the GNU C library. Therefore, the GNU C library provides a means
|
||||
in @theglibc{}. Therefore, @theglibc{} provides a means
|
||||
for tuning the AIO implementation according to the individual use.
|
||||
|
||||
@comment aio.h
|
||||
|
@ -350,8 +350,8 @@ The empty name says to select a locale based on environment variables.
|
||||
@end table
|
||||
|
||||
Defining and installing named locales is normally a responsibility of
|
||||
the system administrator at your site (or the person who installed the
|
||||
GNU C library). It is also possible for the user to create private
|
||||
the system administrator at your site (or the person who installed
|
||||
@theglibc{}). It is also possible for the user to create private
|
||||
locales. All this will be discussed later when describing the tool to
|
||||
do so.
|
||||
@comment (@pxref{Building Locale Files}).
|
||||
@ -889,7 +889,7 @@ The same as the value returned by @code{localeconv} in the
|
||||
@item YESEXPR
|
||||
The return value is a regular expression which can be used with the
|
||||
@code{regex} function to recognize a positive response to a yes/no
|
||||
question. The GNU C library provides the @code{rpmatch} function for
|
||||
question. @Theglibc{} provides the @code{rpmatch} function for
|
||||
easier handling in applications.
|
||||
@item NOEXPR
|
||||
The return value is a regular expression which can be used with the
|
||||
@ -1048,7 +1048,7 @@ than given by the field width, the displayed value is rounded. If the
|
||||
number of fractional digits is selected to be zero, no decimal point is
|
||||
printed.
|
||||
|
||||
As a GNU extension, the @code{strfmon} implementation in the GNU libc
|
||||
As a GNU extension, the @code{strfmon} implementation in @theglibc{}
|
||||
allows an optional @samp{L} next as a format modifier. If this modifier
|
||||
is given, the argument is expected to be a @code{long double} instead of
|
||||
a @code{double} value.
|
||||
@ -1179,7 +1179,7 @@ sure that you localize the answers too. It would be very bad habit to
|
||||
ask a question in one language and request the answer in another, often
|
||||
English.
|
||||
|
||||
The GNU C library contains @code{rpmatch} to give applications easy
|
||||
@Theglibc{} contains @code{rpmatch} to give applications easy
|
||||
access to the corresponding locale definitions.
|
||||
|
||||
@comment GNU
|
||||
@ -1203,7 +1203,7 @@ The answer matched neither the @code{YESEXPR} nor the @code{NOEXPR}
|
||||
regular expression.
|
||||
@end table
|
||||
|
||||
This function is not standardized but available beside in GNU libc at
|
||||
This function is not standardized but available beside in @theglibc{} at
|
||||
least also in the IBM AIX library.
|
||||
@end deftypefun
|
||||
|
||||
|
20
manual/macros.texi
Normal file
20
manual/macros.texi
Normal file
@ -0,0 +1,20 @@
|
||||
@c Define common macros used to keep phrasing consistent in the manual.
|
||||
|
||||
@ifclear MACROS
|
||||
@set MACROS
|
||||
|
||||
@c Names used to refer to the library, as noun phrases at the start or
|
||||
@c not at the start of a sentence.
|
||||
@macro Theglibc
|
||||
The GNU C Library
|
||||
@end macro
|
||||
@macro theglibc
|
||||
the GNU C Library
|
||||
@end macro
|
||||
|
||||
@c Name used to refer to the library as an adjective.
|
||||
@macro glibcadj
|
||||
GNU C Library
|
||||
@end macro
|
||||
|
||||
@end ifclear
|
@ -4,8 +4,8 @@
|
||||
|
||||
@menu
|
||||
* Source Layout:: How to add new functions or header files
|
||||
to the GNU C library.
|
||||
* Porting:: How to port the GNU C library to
|
||||
to the GNU C Library.
|
||||
* Porting:: How to port the GNU C Library to
|
||||
a new machine or operating system.
|
||||
@end menu
|
||||
|
||||
@ -105,9 +105,9 @@ This variable is used for secondary object files needed to build
|
||||
@end table
|
||||
|
||||
@node Porting
|
||||
@appendixsec Porting the GNU C Library
|
||||
@appendixsec Porting @theglibc{}
|
||||
|
||||
The GNU C library is written to be easily portable to a variety of
|
||||
@Theglibc{} is written to be easily portable to a variety of
|
||||
machines and operating systems. Machine- and operating system-dependent
|
||||
functions are well separated to make it easy to add implementations for
|
||||
new machines or operating systems. This section describes the layout of
|
||||
@ -405,7 +405,7 @@ the @file{sysdeps} hierarchy, parallel to @file{unix} and @file{mach}.
|
||||
@end table
|
||||
|
||||
@node Porting to Unix
|
||||
@appendixsubsec Porting the GNU C Library to Unix Systems
|
||||
@appendixsubsec Porting @theglibc{} to Unix Systems
|
||||
|
||||
Most Unix systems are fundamentally very similar. There are variations
|
||||
between different machines, and variations in what facilities are
|
||||
@ -452,10 +452,10 @@ generated are @file{ioctls.h}, @file{errnos.h}, @file{sys/param.h}, and
|
||||
@c It's not anymore true. glibc 2.1 cannot be used with K&R compilers.
|
||||
@c --drepper
|
||||
|
||||
Although the GNU C library implements the @w{ISO C} library facilities, you
|
||||
@emph{can} use the GNU C library with traditional, ``pre-ISO'' C
|
||||
Although @theglibc{} implements the @w{ISO C} library facilities, you
|
||||
@emph{can} use @theglibc{} with traditional, ``pre-ISO'' C
|
||||
compilers. However, you need to be careful because the content and
|
||||
organization of the GNU C library header files differs from that of
|
||||
organization of the @glibcadj{} header files differs from that of
|
||||
traditional C implementations. This means you may need to make changes
|
||||
to your program in order to get it to compile.
|
||||
@end ignore
|
||||
|
@ -111,8 +111,8 @@ These constants come from the Unix98 standard and were also available in
|
||||
defined. The default set of features includes these constants.
|
||||
@xref{Feature Test Macros}.
|
||||
|
||||
All values are of type @code{double}. As an extension, the GNU C
|
||||
library also defines these constants with type @code{long double}. The
|
||||
All values are of type @code{double}. As an extension, @theglibc{}
|
||||
also defines these constants with type @code{long double}. The
|
||||
@code{long double} macros have a lowercase @samp{l} appended to their
|
||||
names: @code{M_El}, @code{M_PIl}, and so forth. These are only
|
||||
available if @code{_GNU_SOURCE} is defined.
|
||||
@ -121,7 +121,7 @@ available if @code{_GNU_SOURCE} is defined.
|
||||
@emph{Note:} Some programs use a constant named @code{PI} which has the
|
||||
same value as @code{M_PI}. This constant is not standard; it may have
|
||||
appeared in some old AT&T headers, and is mentioned in Stroustrup's book
|
||||
on C++. It infringes on the user's name space, so the GNU C library
|
||||
on C++. It infringes on the user's name space, so @theglibc{}
|
||||
does not define it. Fixing programs written to expect it is simple:
|
||||
replace @code{PI} with @code{M_PI} throughout, or put @samp{-DPI=M_PI}
|
||||
on the compiler command line.
|
||||
@ -217,7 +217,7 @@ to cope with its absence.
|
||||
@cindex complex trigonometric functions
|
||||
|
||||
@w{ISO C99} defines variants of the trig functions which work on
|
||||
complex numbers. The GNU C library provides these functions, but they
|
||||
complex numbers. @Theglibc{} provides these functions, but they
|
||||
are only useful if your compiler supports the new complex types defined
|
||||
by the standard.
|
||||
@c XXX Change this when gcc is fixed. -zw
|
||||
@ -1275,7 +1275,7 @@ generator. There is no standard meaning for a particular seed value;
|
||||
the same seed, used in different C libraries or on different CPU types,
|
||||
will give you different random numbers.
|
||||
|
||||
The GNU library supports the standard @w{ISO C} random number functions
|
||||
@Theglibc{} supports the standard @w{ISO C} random number functions
|
||||
plus two other sets derived from BSD and SVID. The BSD and @w{ISO C}
|
||||
functions provide identical, somewhat limited functionality. If only a
|
||||
small number of random bits are required, we recommend you use the
|
||||
@ -1306,7 +1306,7 @@ To use these facilities, you should include the header file
|
||||
@comment ISO
|
||||
@deftypevr Macro int RAND_MAX
|
||||
The value of this macro is an integer constant representing the largest
|
||||
value the @code{rand} function can return. In the GNU library, it is
|
||||
value the @code{rand} function can return. In @theglibc{}, it is
|
||||
@code{2147483647}, which is the largest signed integer representable in
|
||||
32 bits. In other libraries, it may be as low as @code{32767}.
|
||||
@end deftypevr
|
||||
@ -1355,7 +1355,7 @@ available.
|
||||
|
||||
This section describes a set of random number generation functions that
|
||||
are derived from BSD. There is no advantage to using these functions
|
||||
with the GNU C library; we support them for BSD compatibility only.
|
||||
with @theglibc{}; we support them for BSD compatibility only.
|
||||
|
||||
The prototypes for these functions are in @file{stdlib.h}.
|
||||
@pindex stdlib.h
|
||||
@ -1419,7 +1419,7 @@ the user and can only be modified by these functions. This makes it
|
||||
hard to deal with situations where each thread should have its own
|
||||
pseudo-random number generator.
|
||||
|
||||
The GNU C library contains four additional functions which contain the
|
||||
@Theglibc{} contains four additional functions which contain the
|
||||
state as an explicit parameter and therefore make it possible to handle
|
||||
thread-local PRNGs. Beside this there is no difference. In fact, the
|
||||
four functions already discussed are implemented internally using the
|
||||
@ -1824,7 +1824,7 @@ that the cost of the function calls themselves is not negligible.
|
||||
Modern processors can often execute the operations themselves
|
||||
very fast, but the function call disrupts the instruction pipeline.
|
||||
|
||||
For this reason the GNU C Library provides optimizations for many of the
|
||||
For this reason @theglibc{} provides optimizations for many of the
|
||||
frequently-used math functions. When GNU CC is used and the user
|
||||
activates the optimizer, several new inline functions and macros are
|
||||
defined. These new functions and macros have the same names as the
|
||||
|
@ -5,9 +5,9 @@
|
||||
@cindex storage allocation
|
||||
|
||||
This chapter describes how processes manage and use memory in a system
|
||||
that uses the GNU C library.
|
||||
that uses @theglibc{}.
|
||||
|
||||
The GNU C Library has several functions for dynamically allocating
|
||||
@Theglibc{} has several functions for dynamically allocating
|
||||
virtual memory in various ways. They vary in generality and in
|
||||
efficiency. The library also provides functions for controlling paging
|
||||
and allocation of real memory.
|
||||
@ -47,7 +47,7 @@ just a flag saying it is all zeroes.
|
||||
|
||||
The same frame of real memory or backing store can back multiple virtual
|
||||
pages belonging to multiple processes. This is normally the case, for
|
||||
example, with virtual memory occupied by GNU C library code. The same
|
||||
example, with virtual memory occupied by @glibcadj{} code. The same
|
||||
real memory frame containing the @code{printf} function backs a virtual
|
||||
memory page in each of the existing processes that has a @code{printf}
|
||||
call in its program.
|
||||
@ -100,7 +100,7 @@ Allocation and C}).
|
||||
@cindex constants
|
||||
|
||||
Once that program begins to execute, it uses programmatic allocation to
|
||||
gain additional memory. In a C program with the GNU C library, there
|
||||
gain additional memory. In a C program with @theglibc{}, there
|
||||
are two kinds of programmatic allocation: automatic and dynamic.
|
||||
@xref{Memory Allocation and C}.
|
||||
|
||||
@ -158,7 +158,7 @@ grows, but doesn't shrink when the stack shrinks.
|
||||
|
||||
This section covers how ordinary programs manage storage for their data,
|
||||
including the famous @code{malloc} function and some fancier facilities
|
||||
special the GNU C library and GNU Compiler.
|
||||
special @theglibc{} and GNU Compiler.
|
||||
|
||||
@menu
|
||||
* Memory Allocation and C:: How to get different kinds of allocation in C.
|
||||
@ -202,7 +202,7 @@ that varies. In other C implementations, it must be a constant.
|
||||
@end itemize
|
||||
|
||||
A third important kind of memory allocation, @dfn{dynamic allocation},
|
||||
is not supported by C variables but is available via GNU C library
|
||||
is not supported by C variables but is available via @glibcadj{}
|
||||
functions.
|
||||
@cindex dynamic memory allocation
|
||||
|
||||
@ -234,8 +234,8 @@ as you want.
|
||||
Dynamic allocation is not supported by C variables; there is no storage
|
||||
class ``dynamic'', and there can never be a C variable whose value is
|
||||
stored in dynamically allocated space. The only way to get dynamically
|
||||
allocated memory is via a system call (which is generally via a GNU C
|
||||
library function call), and the only way to refer to dynamically
|
||||
allocated memory is via a system call (which is generally via a @glibcadj{}
|
||||
function call), and the only way to refer to dynamically
|
||||
allocated space is through a pointer. Because it is less convenient,
|
||||
and because the actual process of dynamic allocation requires more
|
||||
computation time, programmers generally use dynamic allocation only when
|
||||
@ -591,7 +591,7 @@ more time to minimize the wasted space.
|
||||
|
||||
@end ignore
|
||||
|
||||
As opposed to other versions, the @code{malloc} in the GNU C Library
|
||||
As opposed to other versions, the @code{malloc} in @theglibc{}
|
||||
does not round up block sizes to powers of two, neither for large nor
|
||||
for small sizes. Neighboring chunks can be coalesced on a @code{free}
|
||||
no matter what their size is. This makes the implementation suitable
|
||||
@ -620,7 +620,7 @@ power of two than that, use @code{memalign}, @code{posix_memalign}, or
|
||||
@code{valloc}. @code{memalign} is declared in @file{malloc.h} and
|
||||
@code{posix_memalign} is declared in @file{stdlib.h}.
|
||||
|
||||
With the GNU library, you can use @code{free} to free the blocks that
|
||||
With @theglibc{}, you can use @code{free} to free the blocks that
|
||||
@code{memalign}, @code{posix_memalign}, and @code{valloc} return. That
|
||||
does not work in BSD, however---BSD does not provide any way to free
|
||||
such blocks.
|
||||
@ -834,7 +834,7 @@ recompile your application.
|
||||
@subsubsection Memory Allocation Hooks
|
||||
@cindex allocation hooks, for @code{malloc}
|
||||
|
||||
The GNU C library lets you modify the behavior of @code{malloc},
|
||||
@Theglibc{} lets you modify the behavior of @code{malloc},
|
||||
@code{realloc}, and @code{free} by specifying appropriate hook
|
||||
functions. You can use these hooks to help you debug programs that use
|
||||
dynamic memory allocation, for example.
|
||||
@ -1149,7 +1149,7 @@ Long running programs must assure that dynamically allocated objects are
|
||||
freed at the end of their lifetime. If this does not happen the system
|
||||
runs out of memory, sooner or later.
|
||||
|
||||
The @code{malloc} implementation in the GNU C library provides some
|
||||
The @code{malloc} implementation in @theglibc{} provides some
|
||||
simple means to detect such leaks and obtain some information to find
|
||||
the location. To do this the application must be started in a special
|
||||
mode which is enabled by an environment variable. There are no speed
|
||||
@ -1313,8 +1313,8 @@ If you take a look at the output it will look similar to this:
|
||||
|
||||
What this all means is not really important since the trace file is not
|
||||
meant to be read by a human. Therefore no attention is given to
|
||||
readability. Instead there is a program which comes with the GNU C
|
||||
library which interprets the traces and outputs a summary in an
|
||||
readability. Instead there is a program which comes with @theglibc{}
|
||||
which interprets the traces and outputs a summary in an
|
||||
user-friendly way. The program is called @code{mtrace} (it is in fact a
|
||||
Perl script) and it takes one or two arguments. In any case the name of
|
||||
the file with the trace output must be specified. If an optional
|
||||
@ -2344,7 +2344,7 @@ The symbols in this section are declared in @file{unistd.h}.
|
||||
|
||||
You will not normally use the functions in this section, because the
|
||||
functions described in @ref{Memory Allocation} are easier to use. Those
|
||||
are interfaces to a GNU C Library memory allocator that uses the
|
||||
are interfaces to a @glibcadj{} memory allocator that uses the
|
||||
functions below itself. The functions below are simple interfaces to
|
||||
system calls.
|
||||
|
||||
@ -2526,7 +2526,7 @@ define the macro @code{_POSIX_MEMLOCK_RANGE} and the file
|
||||
@code{limits.h} define the macro @code{PAGESIZE} to be the size of a
|
||||
memory page in bytes. It requires that when the @code{mlockall} and
|
||||
@code{munlockall} functions are available, the @file{unistd.h} file
|
||||
define the macro @code{_POSIX_MEMLOCK}. The GNU C library conforms to
|
||||
define the macro @code{_POSIX_MEMLOCK}. @Theglibc{} conforms to
|
||||
this requirement.
|
||||
|
||||
@comment sys/mman.h
|
||||
|
@ -17,7 +17,7 @@ A better solution is to keep the message sets for each language are kept
|
||||
in separate files which are loaded at runtime depending on the language
|
||||
selection of the user.
|
||||
|
||||
The GNU C Library provides two different sets of functions to support
|
||||
@Theglibc{} provides two different sets of functions to support
|
||||
message translation. The problem is that neither of the interfaces is
|
||||
officially defined by the POSIX standard. The @code{catgets} family of
|
||||
functions is defined in the X/Open standard but this is derived from
|
||||
@ -170,8 +170,8 @@ is
|
||||
@end smallexample
|
||||
|
||||
@noindent
|
||||
where @var{prefix} is given to @code{configure} while installing the GNU
|
||||
C Library (this value is in many cases @code{/usr} or the empty string).
|
||||
where @var{prefix} is given to @code{configure} while installing @theglibc{}
|
||||
(this value is in many cases @code{/usr} or the empty string).
|
||||
|
||||
The remaining problem is to decide which must be used. The value
|
||||
decides about the substitution of the format elements mentioned above.
|
||||
@ -439,11 +439,11 @@ detail in the next section.
|
||||
Files in this other format are not human readable. To be easy to use by
|
||||
programs it is a binary file. But the format is byte order independent
|
||||
so translation files can be shared by systems of arbitrary architecture
|
||||
(as long as they use the GNU C Library).
|
||||
(as long as they use @theglibc{}).
|
||||
|
||||
Details about the binary file format are not important to know since
|
||||
these files are always created by the @code{gencat} program. The
|
||||
sources of the GNU C Library also provide the sources for the
|
||||
sources of @theglibc{} also provide the sources for the
|
||||
@code{gencat} program and so the interested reader can look through
|
||||
these source files to learn about the file format.
|
||||
|
||||
@ -730,11 +730,10 @@ translation in the Uniforum group. There never was a real standard
|
||||
defined but still the interface was used in Sun's operation systems.
|
||||
Since this approach fits better in the development process of free
|
||||
software it is also used throughout the GNU project and the GNU
|
||||
@file{gettext} package provides support for this outside the GNU C
|
||||
Library.
|
||||
@file{gettext} package provides support for this outside @theglibc{}.
|
||||
|
||||
The code of the @file{libintl} from GNU @file{gettext} is the same as
|
||||
the code in the GNU C Library. So the documentation in the GNU
|
||||
the code in @theglibc{}. So the documentation in the GNU
|
||||
@file{gettext} manual is also valid for the functionality here. The
|
||||
following text will describe the library functions in detail. But the
|
||||
numerous helper programs are not described in this manual. Instead
|
||||
@ -982,7 +981,7 @@ As the functions described in the last sections already mention separate
|
||||
sets of messages can be selected by a @dfn{domain name}. This is a
|
||||
simple string which should be unique for each program part with uses a
|
||||
separate domain. It is possible to use in one program arbitrary many
|
||||
domains at the same time. E.g., the GNU C Library itself uses a domain
|
||||
domains at the same time. E.g., @theglibc{} itself uses a domain
|
||||
named @code{libc} while the program using the C Library could use a
|
||||
domain named @code{foo}. The important point is that at any time
|
||||
exactly one domain is active. This is controlled with the following
|
||||
@ -1128,7 +1127,7 @@ form, the second the plural form.
|
||||
|
||||
This has the consequence that programs without language catalogs can
|
||||
display the correct strings only if the program itself is written using
|
||||
a Germanic language. This is a limitation but since the GNU C library
|
||||
a Germanic language. This is a limitation but since @theglibc{}
|
||||
(as well as the GNU @code{gettext} package) are written as part of the
|
||||
GNU package and the coding standards for the GNU project require program
|
||||
being written in English, this solution nevertheless fulfills its
|
||||
@ -1552,7 +1551,7 @@ functions as well which look almost identical, except for the parameters
|
||||
and the call to the underlying function.
|
||||
|
||||
Now there is of course the question why such functions do not exist in
|
||||
the GNU C library? There are two parts of the answer to this question.
|
||||
@theglibc{}? There are two parts of the answer to this question.
|
||||
|
||||
@itemize @bullet
|
||||
@item
|
||||
@ -1666,8 +1665,8 @@ The @var{domain_name} part is the name which was either registered using
|
||||
the @code{textdomain} function or which was given to @code{dgettext} or
|
||||
@code{dcgettext} as the first parameter. Now it becomes obvious that a
|
||||
good choice for the domain name in the program code is a string which is
|
||||
closely related to the program/package name. E.g., for the GNU C
|
||||
Library the domain name is @code{libc}.
|
||||
closely related to the program/package name. E.g., for @theglibc{}
|
||||
the domain name is @code{libc}.
|
||||
|
||||
@noindent
|
||||
A limit piece of example code should show how the programmer is supposed
|
||||
@ -1787,7 +1786,7 @@ different character sets the user has to be careful.
|
||||
@node Helper programs for gettext
|
||||
@subsection Programs to handle message catalogs for @code{gettext}
|
||||
|
||||
The GNU C Library does not contain the source code for the programs to
|
||||
@Theglibc{} does not contain the source code for the programs to
|
||||
handle message catalogs for the @code{gettext} functions. As part of
|
||||
the GNU project the GNU gettext package contains everything the
|
||||
developer needs. The functionality provided by the tools in this
|
||||
|
@ -12,9 +12,9 @@ Network Information Service (NIS) and the Domain Name Service (DNS))
|
||||
became popular, and were hacked into the C library, usually with a fixed
|
||||
search order (@pxref{frobnicate, , ,jargon, The Jargon File}).
|
||||
|
||||
The GNU C Library contains a cleaner solution of this problem. It is
|
||||
@Theglibc{} contains a cleaner solution of this problem. It is
|
||||
designed after a method used by Sun Microsystems in the C library of
|
||||
@w{Solaris 2}. GNU C Library follows their name and calls this
|
||||
@w{Solaris 2}. @Theglibc{} follows their name and calls this
|
||||
scheme @dfn{Name Service Switch} (NSS).
|
||||
|
||||
Though the interface might be similar to Sun's version there is no
|
||||
@ -39,7 +39,7 @@ advantages:
|
||||
|
||||
@enumerate
|
||||
@item
|
||||
Contributors can add new services without adding them to GNU C Library.
|
||||
Contributors can add new services without adding them to @theglibc{}.
|
||||
@item
|
||||
The modules can be updated separately.
|
||||
@item
|
||||
@ -364,7 +364,7 @@ system @file{nss_files.so.2}. This is the difference mentioned above.
|
||||
Sun's NSS modules are usable as modules which get indirectly loaded
|
||||
only.
|
||||
|
||||
The NSS modules in the GNU C Library are prepared to be used as normal
|
||||
The NSS modules in @theglibc{} are prepared to be used as normal
|
||||
libraries themselves. This is @emph{not} true at the moment, though.
|
||||
However, the organization of the name space in the modules does not make it
|
||||
impossible like it is for Solaris. Now you can see why the modules are
|
||||
@ -528,8 +528,8 @@ completely aside).
|
||||
@node Adding another Service to NSS, NSS Module Function Internals, Extending NSS, Extending NSS
|
||||
@subsection Adding another Service to NSS
|
||||
|
||||
The sources for a new service need not (and should not) be part of the
|
||||
GNU C Library itself. The developer retains complete control over the
|
||||
The sources for a new service need not (and should not) be part of @theglibc{}
|
||||
itself. The developer retains complete control over the
|
||||
sources and its development. The links between the C library and the
|
||||
new service module consists solely of the interface functions.
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
@c %MENU% Matching shell ``globs'' and regular expressions
|
||||
@chapter Pattern Matching
|
||||
|
||||
The GNU C Library provides pattern matching facilities for two kinds of
|
||||
@Theglibc{} provides pattern matching facilities for two kinds of
|
||||
patterns: regular expressions and file-name wildcards. The library also
|
||||
provides a facility for expanding variable and command references and
|
||||
parsing text into words in the way the shell does.
|
||||
@ -36,7 +36,7 @@ returns the nonzero value @code{FNM_NOMATCH}. The arguments
|
||||
The argument @var{flags} is a combination of flag bits that alter the
|
||||
details of matching. See below for a list of the defined flags.
|
||||
|
||||
In the GNU C Library, @code{fnmatch} cannot experience an ``error''---it
|
||||
In @theglibc{}, @code{fnmatch} cannot experience an ``error''---it
|
||||
always returns an answer for whether the match succeeds. However, other
|
||||
implementations of @code{fnmatch} might sometimes report ``errors''.
|
||||
They would do so by returning nonzero values that are not equal to
|
||||
@ -668,7 +668,7 @@ type @code{glob64_t} which were allocated by @code{glob64}.
|
||||
@node Regular Expressions
|
||||
@section Regular Expression Matching
|
||||
|
||||
The GNU C library supports two interfaces for matching regular
|
||||
@Theglibc{} supports two interfaces for matching regular
|
||||
expressions. One is the standard POSIX.2 interface, and the other is
|
||||
what the GNU system has had for many years.
|
||||
|
||||
|
@ -55,8 +55,8 @@ until the subprogram terminates before you can do anything else.
|
||||
@comment ISO
|
||||
@deftypefun int system (const char *@var{command})
|
||||
@pindex sh
|
||||
This function executes @var{command} as a shell command. In the GNU C
|
||||
library, it always uses the default shell @code{sh} to run the command.
|
||||
This function executes @var{command} as a shell command. In @theglibc{},
|
||||
it always uses the default shell @code{sh} to run the command.
|
||||
In particular, it searches the directories in @code{PATH} to find
|
||||
programs to execute. The return value is @code{-1} if it wasn't
|
||||
possible to create the shell process, and otherwise is the status of the
|
||||
@ -151,7 +151,7 @@ program should include the header files @file{unistd.h} and
|
||||
@comment POSIX.1
|
||||
@deftp {Data Type} pid_t
|
||||
The @code{pid_t} data type is a signed integer type which is capable
|
||||
of representing a process ID. In the GNU library, this is an @code{int}.
|
||||
of representing a process ID. In @theglibc{}, this is an @code{int}.
|
||||
@end deftp
|
||||
|
||||
@comment unistd.h
|
||||
@ -260,8 +260,8 @@ do a long jump out of) the function that called @code{vfork}! This
|
||||
would leave the parent process's control information very confused. If
|
||||
in doubt, use @code{fork} instead.
|
||||
|
||||
Some operating systems don't really implement @code{vfork}. The GNU C
|
||||
library permits you to use @code{vfork} on all systems, but actually
|
||||
Some operating systems don't really implement @code{vfork}. @Theglibc{}
|
||||
permits you to use @code{vfork} on all systems, but actually
|
||||
executes @code{fork} if @code{vfork} isn't available. If you follow
|
||||
the proper precautions for using @code{vfork}, your program will still
|
||||
work even if the system uses @code{fork} instead.
|
||||
@ -694,11 +694,11 @@ signal number of the signal that caused the child process to stop.
|
||||
@node BSD Wait Functions
|
||||
@section BSD Process Wait Functions
|
||||
|
||||
The GNU library also provides these related facilities for compatibility
|
||||
@Theglibc{} also provides these related facilities for compatibility
|
||||
with BSD Unix. BSD uses the @code{union wait} data type to represent
|
||||
status values rather than an @code{int}. The two representations are
|
||||
actually interchangeable; they describe the same bit patterns. The GNU
|
||||
C Library defines macros such as @code{WEXITSTATUS} so that they will
|
||||
actually interchangeable; they describe the same bit patterns. @Theglibc{}
|
||||
defines macros such as @code{WEXITSTATUS} so that they will
|
||||
work on either kind of object, and the @code{wait} function is defined
|
||||
to accept either type of pointer as its @var{status-ptr} argument.
|
||||
|
||||
|
@ -522,7 +522,7 @@ The process tried to set its current limit beyond its maximum limit.
|
||||
When multiple processes simultaneously require CPU time, the system's
|
||||
scheduling policy and process CPU priorities determine which processes
|
||||
get it. This section describes how that determination is made and
|
||||
GNU C library functions to control it.
|
||||
@glibcadj{} functions to control it.
|
||||
|
||||
It is common to refer to CPU scheduling simply as scheduling and a
|
||||
process' CPU priority simply as the process' priority, with the CPU
|
||||
@ -537,7 +537,7 @@ CPU scheduling is a complex issue and different systems do it in wildly
|
||||
different ways. New ideas continually develop and find their way into
|
||||
the intricacies of the various systems' scheduling algorithms. This
|
||||
section discusses the general concepts, some specifics of systems
|
||||
that commonly use the GNU C library, and some standards.
|
||||
that commonly use @theglibc{}, and some standards.
|
||||
|
||||
For simplicity, we talk about CPU contention as if there is only one CPU
|
||||
in the system. But all the same principles apply when a processor has
|
||||
@ -746,7 +746,7 @@ that has absolute priority higher than 0.
|
||||
@node Basic Scheduling Functions
|
||||
@subsection Basic Scheduling Functions
|
||||
|
||||
This section describes functions in the GNU C library for setting the
|
||||
This section describes functions in @theglibc{} for setting the
|
||||
absolute priority and scheduling policy of a process.
|
||||
|
||||
@strong{Portability Note:} On systems that have the functions in this
|
||||
@ -759,7 +759,7 @@ functions to fine tune the scheduling are in @ref{Traditional Scheduling}.
|
||||
Don't try to make too much out of the naming and structure of these
|
||||
functions. They don't match the concepts described in this manual
|
||||
because the functions are as defined by POSIX.1b, but the implementation
|
||||
on systems that use the GNU C library is the inverse of what the POSIX
|
||||
on systems that use @theglibc{} is the inverse of what the POSIX
|
||||
structure contemplates. The POSIX scheme assumes that the primary
|
||||
scheduling parameter is the scheduling policy and that the priority
|
||||
value, if any, is a parameter of the scheduling policy. In the
|
||||
@ -1107,7 +1107,7 @@ other process owned by the same user (or effective user). But only a
|
||||
privileged process can lower its nice value. A privileged process can
|
||||
also raise or lower another process' nice value.
|
||||
|
||||
GNU C Library functions for getting and setting nice values are described in
|
||||
@glibcadj{} functions for getting and setting nice values are described in
|
||||
@xref{Traditional Scheduling Functions}.
|
||||
|
||||
@node Traditional Scheduling Functions
|
||||
@ -1289,7 +1289,7 @@ The POSIX standard up to this date is of not much help to solve this
|
||||
problem. The Linux kernel provides a set of interfaces to allow
|
||||
specifying @emph{affinity sets} for a process. The scheduler will
|
||||
schedule the thread or process on CPUs specified by the affinity
|
||||
masks. The interfaces which the GNU C library define follow to some
|
||||
masks. The interfaces which @theglibc{} define follow to some
|
||||
extend the Linux kernel interface.
|
||||
|
||||
@comment sched.h
|
||||
@ -1554,7 +1554,7 @@ increases its memory usage). The value returned for
|
||||
If all applications together constantly use more than that amount of
|
||||
memory the system is in trouble.
|
||||
|
||||
The GNU C library provides in addition to these already described way to
|
||||
@Theglibc{} provides in addition to these already described way to
|
||||
get this information two functions. They are declared in the file
|
||||
@file{sys/sysinfo.h}. Programmers should prefer to use the
|
||||
@code{sysconf} method described above.
|
||||
@ -1610,7 +1610,7 @@ processors and so the call
|
||||
returns the number of processors which are currently online (i.e.,
|
||||
available).
|
||||
|
||||
For these two pieces of information the GNU C library also provides
|
||||
For these two pieces of information @theglibc{} also provides
|
||||
functions to get the information directly. The functions are declared
|
||||
in @file{sys/sysinfo.h}.
|
||||
|
||||
|
@ -65,7 +65,7 @@ int comparison_fn_t (const void *, const void *);
|
||||
@cindex array search function
|
||||
|
||||
Generally searching for a specific element in an array means that
|
||||
potentially all elements must be checked. The GNU C library contains
|
||||
potentially all elements must be checked. @Theglibc{} contains
|
||||
functions to perform linear search. The prototypes for the following
|
||||
two functions can be found in @file{search.h}.
|
||||
|
||||
@ -269,8 +269,8 @@ information.
|
||||
|
||||
The weakest aspect of this function is that there can be at most one
|
||||
hashing table used through the whole program. The table is allocated
|
||||
in local memory out of control of the programmer. As an extension the
|
||||
GNU C library provides an additional set of functions with an reentrant
|
||||
in local memory out of control of the programmer. As an extension @theglibc{}
|
||||
provides an additional set of functions with an reentrant
|
||||
interface which provide a similar interface but which allow to keep
|
||||
arbitrarily many hashing tables.
|
||||
|
||||
@ -417,7 +417,7 @@ Another common form to organize data for efficient search is to use
|
||||
trees. The @code{tsearch} function family provides a nice interface to
|
||||
functions to organize possibly large amounts of data by providing a mean
|
||||
access time proportional to the logarithm of the number of elements.
|
||||
The GNU C library implementation even guarantees that this bound is
|
||||
@Theglibc{} implementation even guarantees that this bound is
|
||||
never exceeded even for input data which cause problems for simple
|
||||
binary tree implementations.
|
||||
|
||||
|
@ -180,7 +180,7 @@ change the set of blocked signals, and provides an additional pair of
|
||||
functions (@code{sigsetjmp} and @code{siglongjmp}) to get the BSD
|
||||
behavior.
|
||||
|
||||
The behavior of @code{setjmp} and @code{longjmp} in the GNU library is
|
||||
The behavior of @code{setjmp} and @code{longjmp} in @theglibc{} is
|
||||
controlled by feature test macros; see @ref{Feature Test Macros}. The
|
||||
default in the GNU system is the POSIX.1 behavior rather than the BSD
|
||||
behavior.
|
||||
@ -221,7 +221,7 @@ and these functions are more powerful than those discussed in this
|
||||
chapter so far. These function were part of the original @w{System V}
|
||||
API and by this route were added to the Unix API. Beside on branded
|
||||
Unix implementations these interfaces are not widely available. Not all
|
||||
platforms and/or architectures the GNU C Library is available on provide
|
||||
platforms and/or architectures @theglibc{} is available on provide
|
||||
this interface. Use @file{configure} to detect the availability.
|
||||
|
||||
Similar to the @code{jmp_buf} and @code{sigjmp_buf} types used for the
|
||||
@ -325,7 +325,7 @@ execution using (@pxref{Memory-mapped I/O}).
|
||||
@strong{Compatibility note}: The current Unix standard is very imprecise
|
||||
about the way the stack is allocated. All implementations seem to agree
|
||||
that the @code{uc_stack} element must be used but the values stored in
|
||||
the elements of the @code{stack_t} value are unclear. The GNU C library
|
||||
the elements of the @code{stack_t} value are unclear. @Theglibc{}
|
||||
and most other Unix implementations require the @code{ss_sp} value of
|
||||
the @code{uc_stack} element to point to the base of the memory region
|
||||
allocated for the stack and the size of the memory region is stored in
|
||||
|
@ -9,7 +9,7 @@ executing program. Some signals report errors such as references to
|
||||
invalid memory addresses; others report asynchronous events, such as
|
||||
disconnection of a phone line.
|
||||
|
||||
The GNU C library defines a variety of signal types, each for a
|
||||
@Theglibc{} defines a variety of signal types, each for a
|
||||
particular kind of event. Some kinds of events make it inadvisable or
|
||||
impossible for the program to proceed as usual, and the corresponding
|
||||
signals normally abort the program. Other kinds of signals that report
|
||||
@ -307,7 +307,7 @@ BSD systems provide the @code{SIGFPE} handler with an extra argument
|
||||
that distinguishes various causes of the exception. In order to access
|
||||
this argument, you must define the handler to accept two arguments,
|
||||
which means you must cast it to a one-argument function type in order to
|
||||
establish the handler. The GNU library does provide this extra
|
||||
establish the handler. @Theglibc{} does provide this extra
|
||||
argument, but the value is meaningful only on operating systems that
|
||||
provide the information (BSD systems and GNU systems).
|
||||
|
||||
@ -933,7 +933,7 @@ The simplest way to change the action for a signal is to use the
|
||||
@code{signal} function. You can specify a built-in action (such as to
|
||||
ignore the signal), or you can @dfn{establish a handler}.
|
||||
|
||||
The GNU library also implements the more versatile @code{sigaction}
|
||||
@Theglibc{} also implements the more versatile @code{sigaction}
|
||||
facility. This section describes both facilities and gives suggestions
|
||||
on which to use when.
|
||||
|
||||
@ -1044,7 +1044,7 @@ a handler for @code{SIGKILL} or @code{SIGSTOP}.
|
||||
@code{signal} function is that it has different semantics on BSD and
|
||||
SVID systems. The difference is that on SVID systems the signal handler
|
||||
is deinstalled after signal delivery. On BSD systems the
|
||||
handler must be explicitly deinstalled. In the GNU C Library we use the
|
||||
handler must be explicitly deinstalled. In @theglibc{} we use the
|
||||
BSD version by default. To use the SVID version you can either use the
|
||||
function @code{sysv_signal} (see below) or use the @code{_XOPEN_SOURCE}
|
||||
feature select macro (@pxref{Feature Test Macros}). In general, use of these
|
||||
@ -1320,7 +1320,7 @@ Each signal number has its own set of flags. Each call to
|
||||
@code{sigaction} affects one particular signal number, and the flags
|
||||
that you specify apply only to that particular signal.
|
||||
|
||||
In the GNU C library, establishing a handler with @code{signal} sets all
|
||||
In @theglibc{}, establishing a handler with @code{signal} sets all
|
||||
the flags to zero except for @code{SA_RESTART}, whose value depends on
|
||||
the settings you have made with @code{siginterrupt}. @xref{Interrupted
|
||||
Primitives}, to see what this is about.
|
||||
@ -2032,7 +2032,7 @@ atomically.
|
||||
In practice, you can assume that @code{int} is atomic.
|
||||
You can also assume that pointer
|
||||
types are atomic; that is very convenient. Both of these assumptions
|
||||
are true on all of the machines that the GNU C library supports and on
|
||||
are true on all of the machines that @theglibc{} supports and on
|
||||
all POSIX systems we know of.
|
||||
@c ??? This might fail on a 386 that uses 64-bit pointers.
|
||||
|
||||
@ -2077,7 +2077,7 @@ handlers must check for @code{EINTR} after each library function that
|
||||
can return it, in order to try the call again. Often programmers forget
|
||||
to check, which is a common source of error.
|
||||
|
||||
The GNU library provides a convenient way to retry a call after a
|
||||
@Theglibc{} provides a convenient way to retry a call after a
|
||||
temporary failure, with the macro @code{TEMP_FAILURE_RETRY}:
|
||||
|
||||
@comment unistd.h
|
||||
@ -2099,7 +2099,7 @@ approach: to restart the interrupted primitive, instead of making it
|
||||
fail. If you choose this approach, you need not be concerned with
|
||||
@code{EINTR}.
|
||||
|
||||
You can choose either approach with the GNU library. If you use
|
||||
You can choose either approach with @theglibc{}. If you use
|
||||
@code{sigaction} to establish a signal handler, you can specify how that
|
||||
handler should behave. If you specify the @code{SA_RESTART} flag,
|
||||
return from that handler will resume a primitive; otherwise, return from
|
||||
@ -2111,7 +2111,7 @@ function. @xref{BSD Handler}.
|
||||
@c !!! not true now about _BSD_SOURCE
|
||||
When you don't specify with @code{sigaction} or @code{siginterrupt} what
|
||||
a particular handler should do, it uses a default choice. The default
|
||||
choice in the GNU library depends on the feature test macros you have
|
||||
choice in @theglibc{} depends on the feature test macros you have
|
||||
defined. If you define @code{_BSD_SOURCE} or @code{_GNU_SOURCE} before
|
||||
calling @code{signal}, the default is to resume primitives; otherwise,
|
||||
the default is to make them fail with @code{EINTR}. (The library
|
||||
|
@ -15,7 +15,7 @@ network. Sockets are the primary means of communicating with other
|
||||
machines; @code{telnet}, @code{rlogin}, @code{ftp}, @code{talk} and the
|
||||
other familiar network programs use sockets.
|
||||
|
||||
Not all operating systems support sockets. In the GNU library, the
|
||||
Not all operating systems support sockets. In @theglibc{}, the
|
||||
header file @file{sys/socket.h} exists regardless of the operating
|
||||
system, and the socket functions always exist, but if the system does
|
||||
not really support sockets these functions always fail.
|
||||
@ -155,7 +155,7 @@ happy as implementations which use 64-bit values.
|
||||
@node Communication Styles
|
||||
@section Communication Styles
|
||||
|
||||
The GNU library includes support for several different kinds of sockets,
|
||||
@Theglibc{} includes support for several different kinds of sockets,
|
||||
each with different characteristics. This section describes the
|
||||
supported socket types. The symbolic constants listed here are
|
||||
defined in @file{sys/socket.h}.
|
||||
@ -1276,7 +1276,7 @@ associated Internet address.
|
||||
|
||||
The lookup functions above all have one in common: they are not
|
||||
reentrant and therefore unusable in multi-threaded applications.
|
||||
Therefore provides the GNU C library a new set of functions which can be
|
||||
Therefore provides @theglibc{} a new set of functions which can be
|
||||
used in this context.
|
||||
|
||||
@comment netdb.h
|
||||
|
@ -135,8 +135,8 @@ other words, the whitespace separating them is optional.) Thus,
|
||||
@item
|
||||
Options typically precede other non-option arguments.
|
||||
|
||||
The implementations of @code{getopt} and @code{argp_parse} in the GNU C
|
||||
library normally make it appear as if all the option arguments were
|
||||
The implementations of @code{getopt} and @code{argp_parse} in @theglibc{}
|
||||
normally make it appear as if all the option arguments were
|
||||
specified before all the non-option arguments for the purposes of
|
||||
parsing, even if the user of your program intermixed option and
|
||||
non-option arguments. They do this by reordering the elements of the
|
||||
@ -319,7 +319,7 @@ can be safely used in multi-threaded programs
|
||||
@deftypefun {char *} getenv (const char *@var{name})
|
||||
This function returns a string that is the value of the environment
|
||||
variable @var{name}. You must not modify this string. In some non-Unix
|
||||
systems not using the GNU library, it might be overwritten by subsequent
|
||||
systems not using @theglibc{}, it might be overwritten by subsequent
|
||||
calls to @code{getenv} (but not by any other library function). If the
|
||||
environment variable @var{name} is not defined, the value is a null
|
||||
pointer.
|
||||
@ -591,30 +591,30 @@ A system call is a request for service that a program makes of the
|
||||
kernel. The service is generally something that only the kernel has
|
||||
the privilege to do, such as doing I/O. Programmers don't normally
|
||||
need to be concerned with system calls because there are functions in
|
||||
the GNU C library to do virtually everything that system calls do.
|
||||
@theglibc{} to do virtually everything that system calls do.
|
||||
These functions work by making system calls themselves. For example,
|
||||
there is a system call that changes the permissions of a file, but
|
||||
you don't need to know about it because you can just use the GNU C
|
||||
library's @code{chmod} function.
|
||||
you don't need to know about it because you can just use @theglibc{}'s
|
||||
@code{chmod} function.
|
||||
|
||||
@cindex kernel call
|
||||
System calls are sometimes called kernel calls.
|
||||
|
||||
However, there are times when you want to make a system call explicitly,
|
||||
and for that, the GNU C library provides the @code{syscall} function.
|
||||
and for that, @theglibc{} provides the @code{syscall} function.
|
||||
@code{syscall} is harder to use and less portable than functions like
|
||||
@code{chmod}, but easier and more portable than coding the system call
|
||||
in assembler instructions.
|
||||
|
||||
@code{syscall} is most useful when you are working with a system call
|
||||
which is special to your system or is newer than the GNU C library you
|
||||
which is special to your system or is newer than @theglibc{} you
|
||||
are using. @code{syscall} is implemented in an entirely generic way;
|
||||
the function does not know anything about what a particular system
|
||||
call does or even if it is valid.
|
||||
|
||||
The description of @code{syscall} in this section assumes a certain
|
||||
protocol for system calls on the various platforms on which the GNU C
|
||||
library runs. That protocol is not defined by any strong authority, but
|
||||
protocol for system calls on the various platforms on which @theglibc{}
|
||||
runs. That protocol is not defined by any strong authority, but
|
||||
we won't describe it here either because anyone who is coding
|
||||
@code{syscall} probably won't accept anything less than kernel and C
|
||||
library source code as a specification of the interface between them
|
||||
@ -864,7 +864,7 @@ pointer @var{arg}. At normal program termination, the @var{function} is
|
||||
called with two arguments: the @var{status} value passed to @code{exit},
|
||||
and the @var{arg}.
|
||||
|
||||
This function is included in the GNU C library only for compatibility
|
||||
This function is included in @theglibc{} only for compatibility
|
||||
for SunOS, and may not be supported by other implementations.
|
||||
@end deftypefun
|
||||
|
||||
|
@ -116,7 +116,7 @@ shell. (The primitives shells use to implement these facilities are
|
||||
described in @ref{File System Interface}.) Most other operating systems
|
||||
provide similar mechanisms, but the details of how to use them can vary.
|
||||
|
||||
In the GNU C library, @code{stdin}, @code{stdout}, and @code{stderr} are
|
||||
In @theglibc{}, @code{stdin}, @code{stdout}, and @code{stderr} are
|
||||
normal variables which you can set just like any others. For example,
|
||||
to redirect the standard output to a file, you could do:
|
||||
|
||||
@ -196,7 +196,7 @@ Additional characters may appear after these to specify flags for the
|
||||
call. Always put the mode (@samp{r}, @samp{w+}, etc.) first; that is
|
||||
the only part you are guaranteed will be understood by all systems.
|
||||
|
||||
The GNU C library defines one additional character for use in
|
||||
@Theglibc{} defines one additional character for use in
|
||||
@var{opentype}: the character @samp{x} insists on creating a new
|
||||
file---if a file @var{filename} already exists, @code{fopen} fails
|
||||
rather than opening it. If you use @samp{x} you are guaranteed that
|
||||
@ -290,7 +290,7 @@ If the operation fails, a null pointer is returned; otherwise,
|
||||
@code{freopen} has traditionally been used to connect a standard stream
|
||||
such as @code{stdin} with a file of your own choice. This is useful in
|
||||
programs in which use of a standard stream for certain purposes is
|
||||
hard-coded. In the GNU C library, you can simply close the standard
|
||||
hard-coded. In @theglibc{}, you can simply close the standard
|
||||
streams and open new ones with @code{fopen}. But other systems lack
|
||||
this ability, so using @code{freopen} is more portable.
|
||||
|
||||
@ -318,7 +318,7 @@ In some situations it is useful to know whether a given stream is
|
||||
available for reading or writing. This information is normally not
|
||||
available and would have to be remembered separately. Solaris
|
||||
introduced a few functions to get this information from the stream
|
||||
descriptor and these functions are also available in the GNU C library.
|
||||
descriptor and these functions are also available in @theglibc{}.
|
||||
|
||||
@comment stdio_ext.h
|
||||
@comment GNU
|
||||
@ -394,7 +394,7 @@ you are using NFS.
|
||||
The function @code{fclose} is declared in @file{stdio.h}.
|
||||
@end deftypefun
|
||||
|
||||
To close all streams currently available the GNU C Library provides
|
||||
To close all streams currently available @theglibc{} provides
|
||||
another function.
|
||||
|
||||
@comment stdio.h
|
||||
@ -562,7 +562,7 @@ conservative and use locking.
|
||||
|
||||
There are two basic mechanisms to avoid locking. The first is to use
|
||||
the @code{_unlocked} variants of the stream operations. The POSIX
|
||||
standard defines quite a few of those and the GNU library adds a few
|
||||
standard defines quite a few of those and @theglibc{} adds a few
|
||||
more. These variants of the functions behave just like the functions
|
||||
with the name without the suffix except that they do not lock the
|
||||
stream. Using these functions is very desirable since they are
|
||||
@ -598,7 +598,7 @@ the loop terminates. Writing it the way illustrated above allows the
|
||||
manipulation of the buffer of the stream.
|
||||
|
||||
A second way to avoid locking is by using a non-standard function which
|
||||
was introduced in Solaris and is available in the GNU C library as well.
|
||||
was introduced in Solaris and is available in @theglibc{} as well.
|
||||
|
||||
@comment stdio_ext.h
|
||||
@comment GNU
|
||||
@ -1143,7 +1143,7 @@ convenient to have functions to read a line of text from a stream.
|
||||
|
||||
Standard C has functions to do this, but they aren't very safe: null
|
||||
characters and even (for @code{gets}) long lines can confuse them. So
|
||||
the GNU library provides the nonstandard @code{getline} function that
|
||||
@theglibc{} provides the nonstandard @code{getline} function that
|
||||
makes it easy to read lines reliably.
|
||||
|
||||
Another GNU extension, @code{getdelim}, generalizes @code{getline}. It
|
||||
@ -1289,7 +1289,7 @@ returns a null pointer; otherwise it returns @var{s}.
|
||||
|
||||
@strong{Warning:} The @code{gets} function is @strong{very dangerous}
|
||||
because it provides no protection against overflowing the string
|
||||
@var{s}. The GNU library includes it for compatibility only. You
|
||||
@var{s}. @Theglibc{} includes it for compatibility only. You
|
||||
should @strong{always} use @code{fgets} or @code{getline} instead. To
|
||||
remind you of this, the linker (if using GNU @code{ld}) will issue a
|
||||
warning whenever you use @code{gets}.
|
||||
@ -1383,10 +1383,10 @@ character that was actually read from the stream. In fact, it isn't
|
||||
necessary to actually read any characters from the stream before
|
||||
unreading them with @code{ungetc}! But that is a strange way to write a
|
||||
program; usually @code{ungetc} is used only to unread a character that
|
||||
was just read from the same stream. The GNU C library supports this
|
||||
was just read from the same stream. @Theglibc{} supports this
|
||||
even on files opened in binary mode, but other systems might not.
|
||||
|
||||
The GNU C library only supports one character of pushback---in other
|
||||
@Theglibc{} only supports one character of pushback---in other
|
||||
words, it does not work to call @code{ungetc} twice without doing input
|
||||
in between. Other systems might let you push back multiple characters;
|
||||
then reading from the stream retrieves the characters in the reverse
|
||||
@ -1658,7 +1658,7 @@ actual value in effect at runtime can be retrieved by using
|
||||
Definition}.
|
||||
|
||||
Some system have a quite low limit such as @math{9} for @w{System V}
|
||||
systems. The GNU C library has no real limit.
|
||||
systems. @Theglibc{} has no real limit.
|
||||
@end defvr
|
||||
|
||||
If any of the formats has a specification for the parameter position all
|
||||
@ -2149,7 +2149,7 @@ prints @samp{ nowhere }.
|
||||
If there is a @samp{l} modifier present the argument is expected to be of type @code{wchar_t} (or @code{const wchar_t *}).
|
||||
|
||||
If you accidentally pass a null pointer as the argument for a @samp{%s}
|
||||
conversion, the GNU library prints it as @samp{(null)}. We think this
|
||||
conversion, @theglibc{} prints it as @samp{(null)}. We think this
|
||||
is more useful than crashing. But it's not good practice to pass a null
|
||||
argument intentionally.
|
||||
|
||||
@ -2168,7 +2168,7 @@ fprintf (stderr, "can't open `%s': %s\n", filename, strerror (errno));
|
||||
@end smallexample
|
||||
|
||||
@noindent
|
||||
The @samp{%m} conversion is a GNU C library extension.
|
||||
The @samp{%m} conversion is a @glibcadj{} extension.
|
||||
|
||||
The @samp{%p} conversion prints a pointer value. The corresponding
|
||||
argument must be of type @code{void *}. In practice, you can use any
|
||||
@ -2371,7 +2371,7 @@ make_message (char *name, char *value)
|
||||
|
||||
In practice, it is often easier just to use @code{asprintf}, below.
|
||||
|
||||
@strong{Attention:} In versions of the GNU C library prior to 2.1 the
|
||||
@strong{Attention:} In versions of @theglibc{} prior to 2.1 the
|
||||
return value is the number of characters stored, not including the
|
||||
terminating null; unless there was not enough space in @var{s} to
|
||||
store the result in which case @code{-1} is returned. This was
|
||||
@ -2814,7 +2814,7 @@ validate_args (char *format, int nargs, OBJECT *args)
|
||||
@cindex defining new @code{printf} conversions
|
||||
@cindex extending @code{printf}
|
||||
|
||||
The GNU C library lets you define your own custom conversion specifiers
|
||||
@Theglibc{} lets you define your own custom conversion specifiers
|
||||
for @code{printf} template strings, to teach @code{printf} clever ways
|
||||
to print the important data structures of your program.
|
||||
|
||||
@ -2887,7 +2887,7 @@ about this.
|
||||
@c but if you are never going to call @code{parse_printf_format}, you do
|
||||
@c not need to define an arginfo function.
|
||||
|
||||
@strong{Attention:} In the GNU C library versions before 2.0 the
|
||||
@strong{Attention:} In @theglibc{} versions before 2.0 the
|
||||
@var{arginfo-function} function did not need to be installed unless
|
||||
the user used the @code{parse_printf_format} function. This has changed.
|
||||
Now a call to any of the @code{printf} functions will call this
|
||||
@ -3000,7 +3000,7 @@ width. The value is @code{'0'} if the @samp{0} flag was specified, and
|
||||
Now let's look at how to define the handler and arginfo functions
|
||||
which are passed as arguments to @code{register_printf_function}.
|
||||
|
||||
@strong{Compatibility Note:} The interface changed in GNU libc
|
||||
@strong{Compatibility Note:} The interface changed in @theglibc{}
|
||||
version 2.0. Previously the third argument was of type
|
||||
@code{va_list *}.
|
||||
|
||||
@ -3098,7 +3098,7 @@ The output produced by this program looks like:
|
||||
@node Predefined Printf Handlers
|
||||
@subsection Predefined @code{printf} Handlers
|
||||
|
||||
The GNU libc also contains a concrete and useful application of the
|
||||
@Theglibc{} also contains a concrete and useful application of the
|
||||
@code{printf} handler extension. There are two functions available
|
||||
which implement a special way to print floating-point numbers.
|
||||
|
||||
@ -3926,7 +3926,7 @@ previous I/O operation on that stream.
|
||||
@deftypevr Macro int EOF
|
||||
This macro is an integer value that is returned by a number of narrow
|
||||
stream functions to indicate an end-of-file condition, or some other
|
||||
error situation. With the GNU library, @code{EOF} is @code{-1}. In
|
||||
error situation. With @theglibc{}, @code{EOF} is @code{-1}. In
|
||||
other libraries, its value may be some other negative number.
|
||||
|
||||
This symbol is declared in @file{stdio.h}.
|
||||
@ -3937,7 +3937,7 @@ This symbol is declared in @file{stdio.h}.
|
||||
@deftypevr Macro int WEOF
|
||||
This macro is an integer value that is returned by a number of wide
|
||||
stream functions to indicate an end-of-file condition, or some other
|
||||
error situation. With the GNU library, @code{WEOF} is @code{-1}. In
|
||||
error situation. With @theglibc{}, @code{WEOF} is @code{-1}. In
|
||||
other libraries, its value may be some other negative number.
|
||||
|
||||
This symbol is declared in @file{wchar.h}.
|
||||
@ -4094,7 +4094,7 @@ systems, text and binary streams use different file formats, and the
|
||||
only way to read or write ``an ordinary file of text'' that can work
|
||||
with other text-oriented programs is through a text stream.
|
||||
|
||||
In the GNU library, and on all POSIX systems, there is no difference
|
||||
In @theglibc{}, and on all POSIX systems, there is no difference
|
||||
between text streams and binary streams. When you open a stream, you
|
||||
get the same kind of stream regardless of whether you ask for binary.
|
||||
This stream can handle any file content, and has none of the
|
||||
@ -4562,7 +4562,7 @@ necessary since it might be done in situations when terminal input is
|
||||
required and the program wants to be sure that all output is visible on
|
||||
the terminal. But this means that only line buffered streams have to be
|
||||
flushed. Solaris introduced a function especially for this. It was
|
||||
always available in the GNU C library in some form but never officially
|
||||
always available in @theglibc{} in some form but never officially
|
||||
exported.
|
||||
|
||||
@comment stdio_ext.h
|
||||
@ -4584,7 +4584,7 @@ In some situations it might be useful to not flush the output pending
|
||||
for a stream but instead simply forget it. If transmission is costly
|
||||
and the output is not needed anymore this is valid reasoning. In this
|
||||
situation a non-standard function introduced in Solaris and available in
|
||||
the GNU C library can be used.
|
||||
@theglibc{} can be used.
|
||||
|
||||
@comment stdio_ext.h
|
||||
@comment GNU
|
||||
@ -4722,8 +4722,8 @@ This function is provided for compatibility with old BSD code. Use
|
||||
@end deftypefun
|
||||
|
||||
It is possible to query whether a given stream is line buffered or not
|
||||
using a non-standard function introduced in Solaris and available in the
|
||||
GNU C library.
|
||||
using a non-standard function introduced in Solaris and available in
|
||||
@theglibc{}.
|
||||
|
||||
@comment stdio_ext.h
|
||||
@comment GNU
|
||||
@ -4762,7 +4762,7 @@ This function is declared in the @file{stdio_ext.h} header.
|
||||
@node Other Kinds of Streams
|
||||
@section Other Kinds of Streams
|
||||
|
||||
The GNU library provides ways for you to define additional kinds of
|
||||
@Theglibc{} provides ways for you to define additional kinds of
|
||||
streams that do not necessarily correspond to an open file.
|
||||
|
||||
One such type of stream takes input from or writes output to a string.
|
||||
|
@ -3,7 +3,7 @@
|
||||
@chapter String and Array Utilities
|
||||
|
||||
Operations on strings (or arrays of characters) are an important part of
|
||||
many programs. The GNU C library provides an extensive set of string
|
||||
many programs. @Theglibc{} provides an extensive set of string
|
||||
utility functions, including functions for copying, concatenating,
|
||||
comparing, and searching strings. Many of these functions can also
|
||||
operate on arbitrary regions of storage; for example, the @code{memcpy}
|
||||
@ -669,7 +669,7 @@ the end of the string @var{wto} (that is, the address of the terminating
|
||||
null character @code{wto + strlen (wfrom)}) rather than the beginning.
|
||||
|
||||
This function is not part of ISO or POSIX but was found useful while
|
||||
developing the GNU C Library itself.
|
||||
developing @theglibc{} itself.
|
||||
|
||||
The behavior of @code{wcpcpy} is undefined if the strings overlap.
|
||||
|
||||
@ -695,7 +695,7 @@ is implemented to be useful in contexts where this behavior of the
|
||||
@emph{first} written null character.
|
||||
|
||||
This function is not part of ISO or POSIX but was found useful while
|
||||
developing the GNU C Library itself.
|
||||
developing @theglibc{} itself.
|
||||
|
||||
Its behavior is undefined if the strings overlap. The function is
|
||||
declared in @file{string.h}.
|
||||
@ -721,7 +721,7 @@ is implemented to be useful in contexts where this behavior of the
|
||||
@emph{first} written null character.
|
||||
|
||||
This function is not part of ISO or POSIX but was found useful while
|
||||
developing the GNU C Library itself.
|
||||
developing @theglibc{} itself.
|
||||
|
||||
Its behavior is undefined if the strings overlap.
|
||||
|
||||
@ -1712,7 +1712,7 @@ There is no restriction on the second parameter of @code{strchr} so it
|
||||
could very well also be the NUL character. Those readers thinking very
|
||||
hard about this might now point out that the @code{strchr} function is
|
||||
more expensive than the @code{strlen} function since we have two abort
|
||||
criteria. This is right. But in the GNU C library the implementation of
|
||||
criteria. This is right. But in @theglibc{} the implementation of
|
||||
@code{strchr} is optimized in a special way so that @code{strchr}
|
||||
actually is faster.
|
||||
|
||||
@ -2027,7 +2027,7 @@ when @code{strtok} or @code{wcstok} tries to modify it, your program
|
||||
will get a fatal signal for writing in read-only memory. @xref{Program
|
||||
Error Signals}. Even if the operation of @code{strtok} or @code{wcstok}
|
||||
would not require a modification of the string (e.g., if there is
|
||||
exactly one token) the string can (and in the GNU libc case will) be
|
||||
exactly one token) the string can (and in the @glibcadj{} case will) be
|
||||
modified.
|
||||
|
||||
This is a special case of a general principle: if a part of a program
|
||||
@ -2064,7 +2064,7 @@ token = strtok (NULL, delimiters); /* token => "punctuation" */
|
||||
token = strtok (NULL, delimiters); /* token => NULL */
|
||||
@end smallexample
|
||||
|
||||
The GNU C library contains two more functions for tokenizing a string
|
||||
@Theglibc{} contains two more functions for tokenizing a string
|
||||
which overcome the limitation of non-reentrancy. They are only
|
||||
available for multibyte character strings.
|
||||
|
||||
@ -2220,8 +2220,8 @@ function can be found in @file{libgen.h}.
|
||||
The function below addresses the perennial programming quandary: ``How do
|
||||
I take good data in string form and painlessly turn it into garbage?''
|
||||
This is actually a fairly simple task for C programmers who do not use
|
||||
the GNU C library string functions, but for programs based on the GNU C
|
||||
library, the @code{strfry} function is the preferred method for
|
||||
@theglibc{} string functions, but for programs based on @theglibc{},
|
||||
the @code{strfry} function is the preferred method for
|
||||
destroying string data.
|
||||
|
||||
The prototype for this function is in @file{string.h}.
|
||||
@ -2237,7 +2237,7 @@ input with the anagram in place. For each position in the string,
|
||||
|
||||
The return value of @code{strfry} is always @var{string}.
|
||||
|
||||
@strong{Portability Note:} This function is unique to the GNU C library.
|
||||
@strong{Portability Note:} This function is unique to @theglibc{}.
|
||||
|
||||
@end deftypefun
|
||||
|
||||
@ -2278,7 +2278,7 @@ want to see it or doesn't want to see it very much. To really prevent
|
||||
people from retrieving the information, use stronger encryption such as
|
||||
that described in @xref{Cryptographic Functions}.
|
||||
|
||||
@strong{Portability Note:} This function is unique to the GNU C library.
|
||||
@strong{Portability Note:} This function is unique to @theglibc{}.
|
||||
|
||||
@end deftypefun
|
||||
|
||||
|
@ -97,7 +97,7 @@ this array, in bytes. Note that this is @emph{not} the DNS hostname.
|
||||
If the system participates in DNS, this is the FQDN (see above).
|
||||
|
||||
The return value is @code{0} on success and @code{-1} on failure. In
|
||||
the GNU C library, @code{gethostname} fails if @var{size} is not large
|
||||
@theglibc{}, @code{gethostname} fails if @var{size} is not large
|
||||
enough; then you can try again with a larger array. The following
|
||||
@code{errno} error condition is defined for this function:
|
||||
|
||||
@ -251,8 +251,8 @@ system.
|
||||
This is a description of the type of hardware that is in use.
|
||||
|
||||
Some systems provide a mechanism to interrogate the kernel directly for
|
||||
this information. On systems without such a mechanism, the GNU C
|
||||
library fills in this field based on the configuration name that was
|
||||
this information. On systems without such a mechanism, @theglibc{}
|
||||
fills in this field based on the configuration name that was
|
||||
specified when building and installing the library.
|
||||
|
||||
GNU uses a three-part name to describe a system configuration; the three
|
||||
@ -276,8 +276,8 @@ hardware, it consists of the first two parts of the configuration name:
|
||||
@end quotation
|
||||
|
||||
@item char nodename[]
|
||||
This is the host name of this particular computer. In the GNU C
|
||||
library, the value is the same as that returned by @code{gethostname};
|
||||
This is the host name of this particular computer. In @theglibc{},
|
||||
the value is the same as that returned by @code{gethostname};
|
||||
see @ref{Host Identification}.
|
||||
|
||||
@ gethostname() is implemented with a call to uname().
|
||||
@ -344,7 +344,7 @@ gets stored.
|
||||
|
||||
For some programs it is desirable and necessary to access information
|
||||
about whether a certain filesystem is mounted and, if it is, where, or
|
||||
simply to get lists of all the available filesystems. The GNU libc
|
||||
simply to get lists of all the available filesystems. @Theglibc{}
|
||||
provides some functions to retrieve this information portably.
|
||||
|
||||
Traditionally Unix systems have a file named @file{/etc/fstab} which
|
||||
@ -465,7 +465,7 @@ related to the @code{dump} utility used on Unix systems.
|
||||
@end deftp
|
||||
|
||||
|
||||
To read the entire content of the of the @file{fstab} file the GNU libc
|
||||
To read the entire content of the of the @file{fstab} file @theglibc{}
|
||||
contains a set of three functions which are designed in the usual way.
|
||||
|
||||
@comment fstab.h
|
||||
@ -634,8 +634,8 @@ which is uninteresting for all programs beside @code{dump}.
|
||||
For accessing the @file{mtab} file there is again a set of three
|
||||
functions to access all entries in a row. Unlike the functions to
|
||||
handle @file{fstab} these functions do not access a fixed file and there
|
||||
is even a thread safe variant of the get function. Beside this the GNU
|
||||
libc contains functions to alter the file and test for specific options.
|
||||
is even a thread safe variant of the get function. Beside this @theglibc
|
||||
contains functions to alter the file and test for specific options.
|
||||
|
||||
@comment mntent.h
|
||||
@comment BSD
|
||||
@ -1184,7 +1184,7 @@ cat /proc/sys/vm/freepages
|
||||
@c possible to create a sysctl-only parameter.
|
||||
|
||||
Some more traditional and more widely available, though less general,
|
||||
GNU C library functions for getting and setting some of the same system
|
||||
@glibcadj{} functions for getting and setting some of the same system
|
||||
parameters are:
|
||||
|
||||
@itemize @bullet
|
||||
|
@ -107,11 +107,11 @@ Syslog facility/priority (It can be both because the facility code for
|
||||
the kernel is zero, and that makes priority and facility/priority the
|
||||
same value).
|
||||
|
||||
The GNU C library provides functions to submit messages to Syslog. They
|
||||
@Theglibc{} provides functions to submit messages to Syslog. They
|
||||
do it by writing to the @file{/dev/log} socket. @xref{Submitting Syslog
|
||||
Messages}.
|
||||
|
||||
The GNU C library functions only work to submit messages to the Syslog
|
||||
The @glibcadj{} functions only work to submit messages to the Syslog
|
||||
facility on the same system. To submit a message to the Syslog facility
|
||||
on another system, use the socket I/O functions to write a UDP datagram
|
||||
to the @code{syslog} UDP port on that system. @xref{Sockets}.
|
||||
@ -120,7 +120,7 @@ to the @code{syslog} UDP port on that system. @xref{Sockets}.
|
||||
@node Submitting Syslog Messages
|
||||
@section Submitting Syslog Messages
|
||||
|
||||
The GNU C library provides functions to submit messages to the Syslog
|
||||
@Theglibc{} provides functions to submit messages to the Syslog
|
||||
facility:
|
||||
|
||||
@menu
|
||||
@ -341,7 +341,7 @@ Results are undefined if the facility code is anything else.
|
||||
the kernel. But you can't specify that facility code with these
|
||||
functions. If you try, it looks the same to @code{syslog} as if you are
|
||||
requesting the default facility. But you wouldn't want to anyway,
|
||||
because any program that uses the GNU C library is not the kernel.
|
||||
because any program that uses @theglibc{} is not the kernel.
|
||||
|
||||
You can use just a priority code as @var{facility_priority}. In that
|
||||
case, @code{syslog} assumes the default facility established when the
|
||||
@ -429,8 +429,8 @@ to @var{ident}. The default identification string is the program name
|
||||
taken from argv[0].
|
||||
|
||||
If you are writing shared library code that uses @code{openlog} to
|
||||
generate custom syslog output, you should use @code{closelog} to drop the
|
||||
GNU C library's internal reference to the @var{ident} pointer when you are
|
||||
generate custom syslog output, you should use @code{closelog} to drop
|
||||
@theglibc{}'s internal reference to the @var{ident} pointer when you are
|
||||
done. Please read the section on @code{openlog} for more information:
|
||||
@xref{openlog}.
|
||||
|
||||
|
@ -1068,7 +1068,7 @@ which device you plan to set the speed for. If you use @code{tcsetattr}
|
||||
to set the speed of a particular device to a value that it cannot
|
||||
handle, @code{tcsetattr} returns @math{-1}.
|
||||
|
||||
@strong{Portability note:} In the GNU library, the functions above
|
||||
@strong{Portability note:} In @theglibc{}, the functions above
|
||||
accept speeds measured in bits per second as input, and return speed
|
||||
values measured in bits per second. Other libraries require speeds to
|
||||
be indicated by special codes. For POSIX.1 portability, you must use
|
||||
@ -1612,7 +1612,7 @@ system for a subsequent call to @code{read}.
|
||||
actually the same as the EOF and EOL slots. This causes no serious
|
||||
problem because the MIN and TIME slots are used only in noncanonical
|
||||
input and the EOF and EOL slots are used only in canonical input, but it
|
||||
isn't very clean. The GNU library allocates separate slots for these
|
||||
isn't very clean. @Theglibc{} allocates separate slots for these
|
||||
uses.
|
||||
|
||||
@comment termios.h
|
||||
@ -1642,7 +1642,7 @@ It does exactly this:
|
||||
The usual way to get and set terminal modes is with the functions described
|
||||
in @ref{Terminal Modes}. However, on some systems you can use the
|
||||
BSD-derived functions in this section to do some of the same thing. On
|
||||
many systems, these functions do not exist. Even with the GNU C library,
|
||||
many systems, these functions do not exist. Even with @theglibc{},
|
||||
the functions simply fail with @code{errno} = @code{ENOSYS} with many
|
||||
kernels, including Linux.
|
||||
|
||||
|
@ -89,8 +89,8 @@ other systems, the @code{time_t} data type might use some other encoding
|
||||
where subtraction doesn't work directly.
|
||||
@end deftypefun
|
||||
|
||||
The GNU C library provides two data types specifically for representing
|
||||
an elapsed time. They are used by various GNU C library functions, and
|
||||
@Theglibc{} provides two data types specifically for representing
|
||||
an elapsed time. They are used by various @glibcadj{} functions, and
|
||||
you can use them for your own purposes too. They're exactly the same
|
||||
except that one has a resolution in microseconds, and the other, newer
|
||||
one, is in nanoseconds.
|
||||
@ -173,7 +173,7 @@ Common functions that use @code{struct timeval} are @code{gettimeofday}
|
||||
and @code{settimeofday}.
|
||||
|
||||
|
||||
There are no GNU C library functions specifically oriented toward
|
||||
There are no @glibcadj{} functions specifically oriented toward
|
||||
dealing with elapsed times, but the calendar time, processor time, and
|
||||
alarm and sleeping functions have a lot to do with them.
|
||||
|
||||
@ -356,7 +356,7 @@ and @code{tms_stime} fields returned by @code{times}.
|
||||
This section describes facilities for keeping track of calendar time.
|
||||
@xref{Time Basics}.
|
||||
|
||||
The GNU C library represents calendar time three ways:
|
||||
@Theglibc{} represents calendar time three ways:
|
||||
|
||||
@itemize @bullet
|
||||
@item
|
||||
@ -423,7 +423,7 @@ Note that a simple time has no concept of local time zone. Calendar
|
||||
Time @var{T} is the same instant in time regardless of where on the
|
||||
globe the computer is.
|
||||
|
||||
In the GNU C library, @code{time_t} is equivalent to @code{long int}.
|
||||
In @theglibc{}, @code{time_t} is equivalent to @code{long int}.
|
||||
In other systems, @code{time_t} might be either an integer or
|
||||
floating-point type.
|
||||
@end deftp
|
||||
@ -474,7 +474,7 @@ The process is not superuser.
|
||||
The @code{time_t} data type used to represent simple times has a
|
||||
resolution of only one second. Some applications need more precision.
|
||||
|
||||
So, the GNU C library also contains functions which are capable of
|
||||
So, @theglibc{} also contains functions which are capable of
|
||||
representing calendar times to a higher resolution than one second. The
|
||||
functions and the associated data types described in this section are
|
||||
declared in @file{sys/time.h}.
|
||||
@ -616,7 +616,7 @@ This function is present only with a Linux kernel.
|
||||
@cindex broken-down time
|
||||
@cindex calendar time and broken-down time
|
||||
|
||||
Calendar time is represented by the usual GNU C library functions as an
|
||||
Calendar time is represented by the usual @glibcadj{} functions as an
|
||||
elapsed time since a fixed base calendar time. This is convenient for
|
||||
computation, but has no relation to the way people normally think of
|
||||
calendar time. By contrast, @dfn{broken-down time} is a binary
|
||||
@ -1018,7 +1018,7 @@ The process specified a settings update, but is not superuser.
|
||||
For more details see RFC1305 (Network Time Protocol, Version 3) and
|
||||
related documents.
|
||||
|
||||
@strong{Portability note:} Early versions of the GNU C library did not
|
||||
@strong{Portability note:} Early versions of @theglibc{} did not
|
||||
have this function but did have the synonymous @code{adjtimex}.
|
||||
|
||||
@end deftypefun
|
||||
@ -1775,7 +1775,7 @@ which can match zero or more whitespace characters in the format string.
|
||||
@strong{Portability Note:} The XPG standard advises applications to use
|
||||
at least one whitespace character (as specified by @code{isspace}) or
|
||||
other non-alphanumeric characters between any two conversion
|
||||
specifications. The @w{GNU C Library} does not have this limitation but
|
||||
specifications. @Theglibc{} does not have this limitation but
|
||||
other libraries might have trouble parsing formats like
|
||||
@code{"%d%m%Y%H%M%S"}.
|
||||
|
||||
@ -1800,7 +1800,7 @@ does not specify what happens to those elements of @var{tm} which are
|
||||
not directly initialized by the different formats. The
|
||||
implementations on different Unix systems vary here.
|
||||
|
||||
The GNU libc implementation does not touch those fields which are not
|
||||
The @glibcadj{} implementation does not touch those fields which are not
|
||||
directly initialized. Exceptions are the @code{tm_wday} and
|
||||
@code{tm_yday} elements, which are recomputed if any of the year, month,
|
||||
or date elements changed. This has two implications:
|
||||
@ -2036,7 +2036,7 @@ different time zone, and would like times reported to you in the time
|
||||
zone local to you, rather than what is local to the computer.
|
||||
|
||||
In POSIX.1 systems the value of the @code{TZ} variable can be in one of
|
||||
three formats. With the GNU C library, the most common format is the
|
||||
three formats. With @theglibc{}, the most common format is the
|
||||
last one, which can specify a selection from a large database of time
|
||||
zone information for many regions of the world. The first two formats
|
||||
are used to describe the time zone information directly, which is both
|
||||
@ -2137,16 +2137,16 @@ The third format looks like this:
|
||||
:@var{characters}
|
||||
@end smallexample
|
||||
|
||||
Each operating system interprets this format differently; in the GNU C
|
||||
library, @var{characters} is the name of a file which describes the time
|
||||
Each operating system interprets this format differently; in
|
||||
@theglibc{}, @var{characters} is the name of a file which describes the time
|
||||
zone.
|
||||
|
||||
@pindex /etc/localtime
|
||||
@pindex localtime
|
||||
If the @code{TZ} environment variable does not have a value, the
|
||||
operation chooses a time zone by default. In the GNU C library, the
|
||||
operation chooses a time zone by default. In @theglibc{}, the
|
||||
default time zone is like the specification @samp{TZ=:/etc/localtime}
|
||||
(or @samp{TZ=:/usr/local/etc/localtime}, depending on how GNU C library
|
||||
(or @samp{TZ=:/usr/local/etc/localtime}, depending on how @theglibc{}
|
||||
was configured; @pxref{Installation}). Other C libraries use their own
|
||||
rule for choosing the default time zone, so there is little we can say
|
||||
about them.
|
||||
@ -2163,7 +2163,7 @@ subdirectories for geographical areas; for example,
|
||||
@file{America/New_York}, @file{Europe/London}, @file{Asia/Hong_Kong}.
|
||||
These data files are installed by the system administrator, who also
|
||||
sets @file{/etc/localtime} to point to the data file for the local time
|
||||
zone. The GNU C library comes with a large database of time zone
|
||||
zone. @Theglibc{} comes with a large database of time zone
|
||||
information for most regions of the world, which is maintained by a
|
||||
community of volunteers and put in the public domain.
|
||||
|
||||
|
@ -207,15 +207,15 @@ facilities, you must include the header files @file{sys/types.h} and
|
||||
@comment sys/types.h
|
||||
@comment POSIX.1
|
||||
@deftp {Data Type} uid_t
|
||||
This is an integer data type used to represent user IDs. In the GNU
|
||||
library, this is an alias for @code{unsigned int}.
|
||||
This is an integer data type used to represent user IDs. In
|
||||
@theglibc{}, this is an alias for @code{unsigned int}.
|
||||
@end deftp
|
||||
|
||||
@comment sys/types.h
|
||||
@comment POSIX.1
|
||||
@deftp {Data Type} gid_t
|
||||
This is an integer data type used to represent group IDs. In the GNU
|
||||
library, this is an alias for @code{unsigned int}.
|
||||
This is an integer data type used to represent group IDs. In
|
||||
@theglibc{}, this is an alias for @code{unsigned int}.
|
||||
@end deftp
|
||||
|
||||
@comment unistd.h
|
||||
@ -1118,7 +1118,7 @@ the user accounting database.
|
||||
All the @code{get*} functions mentioned before store the information
|
||||
they return in a static buffer. This can be a problem in multi-threaded
|
||||
programs since the data returned for the request is overwritten by the
|
||||
return value data in another thread. Therefore the GNU C Library
|
||||
return value data in another thread. Therefore @theglibc{}
|
||||
provides as extensions three more functions which return the data in a
|
||||
user-provided buffer.
|
||||
|
||||
@ -1202,7 +1202,7 @@ therefore the return value does not say anything about whether the
|
||||
database can be successfully opened.
|
||||
@end deftypefun
|
||||
|
||||
Specially for maintaining log-like databases the GNU C Library provides
|
||||
Specially for maintaining log-like databases @theglibc{} provides
|
||||
the following function:
|
||||
|
||||
@comment utmp.h
|
||||
@ -1941,7 +1941,7 @@ without loops.
|
||||
|
||||
Sun's implementation allows netgroups only for the @code{nis} or
|
||||
@code{nisplus} service, @pxref{Services in the NSS configuration}. The
|
||||
implementation in the GNU C library has no such restriction. An entry
|
||||
implementation in @theglibc{} has no such restriction. An entry
|
||||
in either of the input services must have the following form:
|
||||
|
||||
@smallexample
|
||||
|
Loading…
Reference in New Issue
Block a user