mirror of
https://sourceware.org/git/glibc.git
synced 2024-12-13 14:50:17 +00:00
Fix typos.
This commit is contained in:
parent
7e916f1696
commit
cd47135c30
4
FAQ.in
4
FAQ.in
@ -1350,7 +1350,7 @@ benchmark program for measuring disk access).
|
||||
{AJ} The GNU C library 2.1 uses db2 instead of db1 which was used in version
|
||||
2.0. The internal formats of the actual db files are different. To convert
|
||||
the db files from db1 format to db2 format, you can use the programs
|
||||
`db_dump185' and `db_load'. Alternativly programs can be linked with db1
|
||||
`db_dump185' and `db_load'. Alternatively programs can be linked with db1
|
||||
using `-ldb1' instead of linking with db2 which uses `-ldb'. Linking with
|
||||
db1 might be preferable if older programs need to access the db file.
|
||||
|
||||
@ -1446,7 +1446,7 @@ reading the POSIX standards.
|
||||
<http://www.gnu.org/software/libc/>. The problem data base of open and
|
||||
solved bugs in GNU libc is available at
|
||||
<http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl>. Eric Green has written
|
||||
a HowTo for converting from Linux libc5 to glibc2. The HowTo is accessable
|
||||
a HowTo for converting from Linux libc5 to glibc2. The HowTo is accessible
|
||||
via the FSF page and at <http://www.imaxx.net/~thrytis/glibc>. Frodo
|
||||
Looijaard describes a different way installing glibc2 as secondary libc at
|
||||
<http://huizen.dds.nl/~frodol/glibc>.
|
||||
|
@ -362,7 +362,7 @@ struct hol_cluster
|
||||
const char *header;
|
||||
|
||||
/* Used to order clusters within the same group with the same parent,
|
||||
according to the order in which they occured in the parent argp's child
|
||||
according to the order in which they occurred in the parent argp's child
|
||||
list. */
|
||||
int index;
|
||||
|
||||
@ -1424,7 +1424,7 @@ argp_args_usage (const struct argp *argp, const struct argp_state *state,
|
||||
following the `\v' character (nothing for strings without). Each separate
|
||||
bit of documentation is separated a blank line, and if PRE_BLANK is true,
|
||||
then the first is as well. If FIRST_ONLY is true, only the first
|
||||
occurance is output. Returns true if anything was output. */
|
||||
occurrence is output. Returns true if anything was output. */
|
||||
static int
|
||||
argp_doc (const struct argp *argp, const struct argp_state *state,
|
||||
int post, int pre_blank, int first_only,
|
||||
|
@ -201,7 +201,7 @@ typedef error_t (*argp_parser_t) __PMT ((int key, char *arg,
|
||||
argp's, and perhaps a function to filter help output. When actually
|
||||
parsing options, getopt is called with the union of all the argp
|
||||
structures chained together through their CHILD pointers, with conflicts
|
||||
being resolved in favor of the first occurance in the chain. */
|
||||
being resolved in favor of the first occurrence in the chain. */
|
||||
struct argp
|
||||
{
|
||||
/* An array of argp_option structures, terminated by an entry with both
|
||||
|
@ -1,5 +1,5 @@
|
||||
/* Storage management for the chain of loaded shared objects.
|
||||
Copyright (C) 1995, 1996, 1997, 1998, 1999 Free Software Foundation, Inc.
|
||||
Copyright (C) 1995-1999, 2000 Free Software Foundation, Inc.
|
||||
This file is part of the GNU C Library.
|
||||
|
||||
The GNU C Library is free software; you can redistribute it and/or
|
||||
@ -59,7 +59,7 @@ _dl_new_object (char *realname, const char *libname, int type,
|
||||
while (l->l_next)
|
||||
l = l->l_next;
|
||||
new->l_prev = l;
|
||||
/* new->l_next = NULL; Would be necesary but we use calloc. */
|
||||
/* new->l_next = NULL; Would be necessary but we use calloc. */
|
||||
l->l_next = new;
|
||||
|
||||
/* Add the global scope. */
|
||||
|
@ -241,7 +241,7 @@ _dl_open (const char *file, int mode, const void *caller)
|
||||
|
||||
if (errstring)
|
||||
{
|
||||
/* Some error occured during loading. */
|
||||
/* Some error occurred during loading. */
|
||||
char *local_errstring;
|
||||
|
||||
/* Remove the object from memory. It may be in an inconsistent
|
||||
|
@ -989,7 +989,7 @@ typedef struct
|
||||
#define EF_MIPS_ARCH_4 0x30000000 /* -mips4 code. */
|
||||
#define EF_MIPS_ARCH_5 0x40000000 /* -mips5 code. */
|
||||
|
||||
/* The following are non-official names and should ot be used. */
|
||||
/* The following are non-official names and should not be used. */
|
||||
|
||||
#define E_MIPS_ARCH_1 0x00000000 /* -mips1 code. */
|
||||
#define E_MIPS_ARCH_2 0x10000000 /* -mips2 code. */
|
||||
|
@ -643,7 +643,7 @@ of this helper program; chances are you did not intend to run this program.\n\
|
||||
_dl_rtld_map.l_prev = _dl_loaded;
|
||||
|
||||
/* We have two ways to specify objects to preload: via environment
|
||||
variable and via the file /etc/ld.so.preload. The later can also
|
||||
variable and via the file /etc/ld.so.preload. The latter can also
|
||||
be used when security is enabled. */
|
||||
preloads = NULL;
|
||||
npreloads = 0;
|
||||
|
@ -1,5 +1,5 @@
|
||||
/* Find matching transformation algorithms and initialize steps.
|
||||
Copyright (C) 1997, 1998, 1999 Free Software Foundation, Inc.
|
||||
Copyright (C) 1997, 1998, 1999, 2000 Free Software Foundation, Inc.
|
||||
This file is part of the GNU C Library.
|
||||
Contributed by Ulrich Drepper <drepper@cygnus.com>, 1997.
|
||||
|
||||
@ -53,7 +53,7 @@ __gconv_open (const char *toset, const char *fromset, gconv_t *handle)
|
||||
nsteps * sizeof (struct gconv_step_data));
|
||||
|
||||
/* Call all initialization functions for the transformation
|
||||
step implemenations. */
|
||||
step implementations. */
|
||||
for (cnt = 0; cnt < nsteps; ++cnt)
|
||||
{
|
||||
/* If this is the last step we must not allocate an
|
||||
|
@ -1,4 +1,4 @@
|
||||
/* Copyright (C) 1995, 1996, 1997, 1998, 1999 Free Software Foundation, Inc.
|
||||
/* Copyright (C) 1995-1999, 2000 Free Software Foundation, Inc.
|
||||
This file is part of the GNU C Library.
|
||||
Contributed by Ulrich Drepper <drepper@gnu.ai.mit.edu>, 1995.
|
||||
|
||||
@ -1418,7 +1418,7 @@ line before ellipsis does not contain definition for character constant"));
|
||||
/* Now it's time to handle the ellipsis in the previous line. We do
|
||||
this only when the last line contained an definition for a
|
||||
character, the current line also defines an character, the
|
||||
character code for the later is bigger than the former. */
|
||||
character code for the latter is bigger than the former. */
|
||||
if (collate->was_ellipsis)
|
||||
{
|
||||
if (collate->kind != character)
|
||||
|
@ -19,7 +19,7 @@
|
||||
# 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
||||
|
||||
# The format of this file is pretty simple: Each line contains a test
|
||||
# for strfmon. Fields are seperated by TABs. Lines that start with a
|
||||
# for strfmon. Fields are separated by TABs. Lines that start with a
|
||||
# '#' are comments and are ignored.
|
||||
#
|
||||
# Field Deskription
|
||||
|
@ -1,6 +1,6 @@
|
||||
#! /bin/sh -f
|
||||
#
|
||||
# Copyright (C) 1998, 1999 Free Software Foundation, Inc.
|
||||
# Copyright (C) 1998, 1999, 2000 Free Software Foundation, Inc.
|
||||
# This file is part of the GNU C Library and contains tests for
|
||||
# the rpmatch(3)-implementation.
|
||||
# contributed by Jochen Hein <jochen.hein@delphi.central.de>
|
||||
@ -31,7 +31,7 @@ while read locale string result dummy; do
|
||||
fi
|
||||
done <<EOF
|
||||
#& These are the tests for rpmatch in glibc. Each line contains one test,
|
||||
#& comments start with #& in the first column. The fields are seperated
|
||||
#& comments start with #& in the first column. The fields are separated
|
||||
#& by paragraph signs and contain: the locale, the string, the expected
|
||||
#& return value of rpmatch(3). If the test fails, test-rpmatch prints
|
||||
#& all these informations
|
||||
|
@ -38,7 +38,7 @@ struct xtmp
|
||||
time_t xt_time; /* Time entry was made. */
|
||||
char xt_user[XT_NAMESIZE]; /* Username (not NUL terminated). */
|
||||
char xt_host[XT_HOSTSIZE]; /* Hostname for remote login. */
|
||||
long xt_addr; /* Internet adress of remote host. */
|
||||
long xt_addr; /* Internet address of remote host. */
|
||||
};
|
||||
|
||||
#define _HAVE_XT_TYPE 1
|
||||
|
@ -2170,7 +2170,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 thse functions,
|
||||
The GNU C library also provides @samp{_l} versions of these functions,
|
||||
which take an additional argument, the locale to use in conversion.
|
||||
@xref{Parsing of Integers}.
|
||||
|
||||
|
@ -524,7 +524,7 @@ The code to emit the escape sequence to get back to the initial state is
|
||||
interesting. The @code{wcsrtombs} function can be used to determine the
|
||||
necessary output code (@pxref{Converting Strings}). Please note that on
|
||||
GNU systems it is not necessary to perform this extra action for the
|
||||
conversion from multibyte text ot wide character text since the wide
|
||||
conversion from multibyte text to wide character text since the wide
|
||||
character encoding is not stateful. But there is nothing mentioned in
|
||||
any standard which prohibits making @code{wchar_t} using a stateful
|
||||
encoding.
|
||||
@ -703,7 +703,7 @@ bytes in the multibyte input string. This method yields to a
|
||||
pessimistic guess about the size of the result and if many wide
|
||||
character strings have to be constructed this way or the strings are
|
||||
long, the extra memory required allocated because the input string
|
||||
contains multibzte characters might be significant. It would be
|
||||
contains multibyte characters might be significant. It would be
|
||||
possible to resize the allocated memory block to the correct size before
|
||||
returning it. A better solution might be to allocate just the right
|
||||
amount of space for the result right away. Unfortunately there is no
|
||||
@ -1633,15 +1633,15 @@ of the conversions from @var{fromset} to @var{toset}.
|
||||
|
||||
The GNU C library 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 to store
|
||||
the necessary files with data and code in arbitrary many directories.
|
||||
How this extensions have to be written will be explained below
|
||||
of the set of available conversions the implementation allows storing
|
||||
the necessary files with data and code in arbitrarily many directories.
|
||||
How this extension has to be written will be explained below
|
||||
(@pxref{glibc iconv Implementation}). Here it is only important to say
|
||||
that all directories mentioned in the @code{GCONV_PATH} environment
|
||||
variable are considered if they contain a file @file{gconv-modules}.
|
||||
These directories need not necessarily be created by the system
|
||||
administrator. In fact, this extension is introduced to help users
|
||||
writing and using own, new conversions. Of course this does not work
|
||||
writing and using their own, new conversions. Of course this does not work
|
||||
for security reasons in SUID binaries; in this case only the system
|
||||
directory is considered and this normally is
|
||||
@file{@var{prefix}/lib/gconv}. The @code{GCONV_PATH} environment
|
||||
@ -2042,7 +2042,7 @@ the GNU C library 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 funtionality has solidified.
|
||||
complete, but basic functionality has solidified.
|
||||
|
||||
The GNU C library's @code{iconv} implementation uses shared loadable
|
||||
modules to implement the conversions. A very small number of
|
||||
@ -2181,7 +2181,7 @@ set.
|
||||
Explaining why the above @file{gconv-modules} files allows the
|
||||
@code{iconv} implementation to resolve the specific ISO-2022-JP to
|
||||
EUC-JP conversion module instead of the conversion coming with the
|
||||
library itself is straighforward. Since the later conversion takes two
|
||||
library itself is straightforward. Since the latter conversion takes two
|
||||
steps (from ISO-2022-JP to @w{ISO 10646} and then from @w{ISO 10646} to
|
||||
EUC-JP) the cost is @math{1+1 = 2}. But the above @file{gconv-modules}
|
||||
file specifies that the new conversion modules can perform this
|
||||
@ -2224,7 +2224,7 @@ so that one can write new ones. This section describes the interface as
|
||||
it is in use in January 1999. The interface will change in future a bit
|
||||
but hopefully only in an upward compatible way.
|
||||
|
||||
The definitions necessary to write new modules are publically available
|
||||
The definitions necessary to write new modules are publicly available
|
||||
in the non-standard header @file{gconv.h}. The following text will
|
||||
therefore describe the definitions from this header file. But first it
|
||||
is necessary to get an overview.
|
||||
@ -2404,13 +2404,13 @@ the GNU C library also use the @code{iconv} functionality which
|
||||
increases the number of uses of the same functions even more.
|
||||
|
||||
For this reason the modules do not get loaded exclusively for one
|
||||
conversion. Instead a module once loaded can be used by arbitrary many
|
||||
conversion. Instead a module once loaded can be used by arbitrarily many
|
||||
@code{iconv} or @code{mbsrtowcs} calls at the same time. The splitting
|
||||
of the information between conversion function specific information and
|
||||
conversion data makes this possible. The last section showed the two
|
||||
data structure used to do this.
|
||||
data structures used to do this.
|
||||
|
||||
This is of course also reflected in the interface and semantic of the
|
||||
This is of course also reflected in the interface and semantics of the
|
||||
functions the modules must provide. There are three functions which
|
||||
must have the following names:
|
||||
|
||||
|
@ -26,10 +26,10 @@ functions with names that smaller ones reserve to the user program. This
|
||||
is not mere pedantry --- it has been a problem in practice. For instance,
|
||||
some non-GNU programs define functions named @code{getline} that have
|
||||
nothing to do with this library's @code{getline}. They would not be
|
||||
compilable if all features were enabled indescriminantly.
|
||||
compilable if all features were enabled indiscriminately.
|
||||
|
||||
This should not be used to verify that a program conforms to a limited
|
||||
standard. It is insufficent for this purpose, as it will not protect you
|
||||
standard. It is insufficient for this purpose, as it will not protect you
|
||||
from including header files outside the standard, or relying on semantics
|
||||
undefined within the standard.
|
||||
|
||||
|
@ -292,7 +292,7 @@ of this the normal character classification functions as used for
|
||||
@comment ISO
|
||||
@deftp {Data type} wctype_t
|
||||
The @code{wctype_t} can hold a value which represents a character class.
|
||||
The ony defined way to generate such a value is by using the
|
||||
The only defined way to generate such a value is by using the
|
||||
@code{wctype} function.
|
||||
|
||||
@pindex wctype.h
|
||||
@ -724,7 +724,7 @@ This function is declared in @file{wctype.h}.
|
||||
@end deftypefun
|
||||
|
||||
The @w{ISO C} standard also defines for the generally available mappings
|
||||
convenient shortcuts so that it is not necesary to call @code{wctrans}
|
||||
convenient shortcuts so that it is not necessary to call @code{wctrans}
|
||||
for them.
|
||||
|
||||
@comment wctype.h
|
||||
@ -765,6 +765,6 @@ This function is declared in @file{wctype.h}.
|
||||
@end deftypefun
|
||||
|
||||
The same warnings given in the last section for the use of the wide
|
||||
character classiffication function applies here. It is not possible to
|
||||
character classification function applies here. It is not possible to
|
||||
simply cast a @code{char} type value to a @code{wint_t} and use it as an
|
||||
argument for @code{towctrans} calls.
|
||||
|
@ -30,7 +30,7 @@ const char *argp_program_bug_address =
|
||||
static char doc[] =
|
||||
"Argp example #2 -- a pretty minimal program using argp";
|
||||
|
||||
/* Our argpument parser. The @code{options}, @code{parser}, and
|
||||
/* Our argument parser. The @code{options}, @code{parser}, and
|
||||
@code{args_doc} fields are zero because we have neither options or
|
||||
arguments; @code{doc} and @code{argp_program_bug_address} will be
|
||||
used in the output for @samp{--help}, and the @samp{--version}
|
||||
|
@ -17,7 +17,7 @@
|
||||
a special key specifying something else; the only
|
||||
special keys we use here are ARGP_KEY_ARG, meaning
|
||||
a non-option argument, and ARGP_KEY_END, meaning
|
||||
that all argumens have been parsed
|
||||
that all arguments have been parsed
|
||||
ARG -- For an option KEY, the string value of its
|
||||
argument, or NULL if it has none
|
||||
STATE-- A pointer to a struct argp_state, containing
|
||||
|
@ -19,7 +19,7 @@
|
||||
is longer, describing the behavior in more detail. All
|
||||
documentation strings are automatically filled for output,
|
||||
although newlines may be included to force a line break at a
|
||||
particular point. All documenation strings are also passed to
|
||||
particular point. All documentation strings are also passed to
|
||||
the `gettext' function, for possible translation into the
|
||||
current locale. */
|
||||
|
||||
|
@ -28,7 +28,7 @@ make_named_socket (const char *filename)
|
||||
the offset of the start of the filename,
|
||||
plus its length,
|
||||
plus one for the terminating null byte.
|
||||
Alternativly you can just do:
|
||||
Alternatively you can just do:
|
||||
size = SUN_LEN (&name);
|
||||
*/
|
||||
size = (offsetof (struct sockaddr_un, sun_path)
|
||||
|
@ -1615,7 +1615,7 @@ which @var{buf} must point.
|
||||
|
||||
When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} this
|
||||
function is available under the name @code{stat} and so transparently
|
||||
replaces the interface for small fiels on 32 bits machines.
|
||||
replaces the interface for small files on 32 bits machines.
|
||||
@end deftypefun
|
||||
|
||||
@comment sys/stat.h
|
||||
@ -1650,7 +1650,7 @@ which is able to represent the larger values.
|
||||
|
||||
When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} this
|
||||
function is available under the name @code{fstat} and so transparently
|
||||
replaces the interface for small fiels on 32 bits machines.
|
||||
replaces the interface for small files on 32 bits machines.
|
||||
@end deftypefun
|
||||
|
||||
@comment sys/stat.h
|
||||
@ -1676,7 +1676,7 @@ which @var{buf} must point.
|
||||
|
||||
When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} this
|
||||
function is available under the name @code{lstat} and so transparently
|
||||
replaces the interface for small fiels on 32 bits machines.
|
||||
replaces the interface for small files on 32 bits machines.
|
||||
@end deftypefun
|
||||
|
||||
@node Testing File Type
|
||||
@ -2511,7 +2511,7 @@ size of @math{0} and is automatically extended when data is written
|
||||
past its end. It is also possible to empty a file completely in an
|
||||
@code{open} or @code{fopen} call.
|
||||
|
||||
However, sometimes it is neccessary to @emph{reduce} the size of a file.
|
||||
However, sometimes it is necessary to @emph{reduce} the size of a file.
|
||||
This can be done with the @code{truncate} and @code{ftruncate} functions.
|
||||
They were introduced in BSD Unix. @code{ftruncate} was later added to
|
||||
POSIX.1.
|
||||
@ -2550,7 +2550,7 @@ The file is a directory or not writable.
|
||||
The operation would extend the file beyond the limits of the operating system.
|
||||
|
||||
@item EIO
|
||||
A hardware I/O error occured.
|
||||
A hardware I/O error occurred.
|
||||
|
||||
@item EPERM
|
||||
The file is "append-only" or "immutable".
|
||||
@ -2592,7 +2592,7 @@ The operation would extend the file beyond the limits of the operating system.
|
||||
@c files with extra-large offsets.
|
||||
|
||||
@item EIO
|
||||
A hardware I/O error occured.
|
||||
A hardware I/O error occurred.
|
||||
|
||||
@item EPERM
|
||||
The file is "append-only" or "immutable".
|
||||
@ -2767,7 +2767,7 @@ the file in any case should use the @code{O_EXCL} flag. Using
|
||||
@comment GNU
|
||||
@deftypefun {char *} tmpnam_r (char *@var{result})
|
||||
This function is nearly identical to the @code{tmpnam} function. But it
|
||||
does not allow @var{result} to be a null pointer. In the later case a
|
||||
does not allow @var{result} to be a null pointer. In the latter case a
|
||||
null pointer is returned.
|
||||
|
||||
This function is reentrant because the non-reentrant situation of
|
||||
|
@ -41,7 +41,7 @@ directly.)
|
||||
or vice-versa.
|
||||
* Stream/Descriptor Precautions:: Precautions needed if you use both
|
||||
descriptors and streams.
|
||||
* Scatter-Gather:: Fast I/O to discontinous buffers.
|
||||
* Scatter-Gather:: Fast I/O to discontinuous buffers.
|
||||
* Memory-mapped I/O:: Using files like memory.
|
||||
* Waiting for I/O:: How to check for input or output
|
||||
on multiple file descriptors.
|
||||
@ -1131,8 +1131,8 @@ Modes}.
|
||||
@cindex scatter-gather
|
||||
|
||||
Some applications may need to read or write data to multiple buffers,
|
||||
which are seperated in memory. Although this can be done easily enough
|
||||
with multiple calls to @code{read} and @code{write}, it is inefficent
|
||||
which are separated in memory. Although this can be done easily enough
|
||||
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
|
||||
@ -1206,7 +1206,7 @@ On modern operating systems, it is possible to @dfn{mmap} (pronounced
|
||||
``em-map'') a file to a region of memory. When this is done, the file can
|
||||
be accessed just like an array in the program.
|
||||
|
||||
This is more efficent than @code{read} or @code{write}, as only regions
|
||||
This is more efficient than @code{read} or @code{write}, as only regions
|
||||
of the file a program actually accesses are loaded. Accesses to
|
||||
not-yet-loaded parts of the mmapped region are handled in the same way as
|
||||
swapped out pages.
|
||||
@ -1250,7 +1250,7 @@ Error Signals}).
|
||||
|
||||
Note that most hardware designs cannot support write permission without
|
||||
read permission, and many do not distinguish read and execute permission.
|
||||
Thus, you may recieve wider permissions than you ask for, and mappings of
|
||||
Thus, you may receive wider permissions than you ask for, and mappings of
|
||||
write-only files may be denied even if you do not use @code{PROT_READ}.
|
||||
|
||||
@var{flags} contains flags that control the nature of the map.
|
||||
@ -1294,7 +1294,7 @@ Anonymous maps are used as the basic primitive to extend the heap on some
|
||||
systems. They are also useful to share data between multiple tasks
|
||||
without creating a file.
|
||||
|
||||
On some systems using private anonymous mmaps is more efficent than using
|
||||
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,
|
||||
as the included @code{malloc} automatically uses @code{mmap} where appropriate.
|
||||
|
||||
@ -1372,8 +1372,8 @@ aligned.
|
||||
|
||||
When using shared mappings, the kernel can write the file at any time
|
||||
before the mapping is removed. To be certain data has actually been
|
||||
written to the file and will be accessable to non-memory-mapped I/O, it
|
||||
is neccessary to use this function.
|
||||
written to the file and will be accessible to non-memory-mapped I/O, it
|
||||
is necessary to use this function.
|
||||
|
||||
It operates on the region @var{address} to (@var{address} + @var{length}).
|
||||
It may be used on part of a mapping or multiple mappings, however the
|
||||
@ -1444,7 +1444,7 @@ The region has pages locked, and if extended it would exceed the
|
||||
process's resource limit for locked pages. @xref{Limits on Resources}.
|
||||
|
||||
@item ENOMEM
|
||||
The region is private writable, and insufficent virtual memory is
|
||||
The region is private writable, and insufficient virtual memory is
|
||||
available to extend it. Also, this error will occur if
|
||||
@code{MREMAP_MAYMOVE} is not given and the extension would collide with
|
||||
another mapped region.
|
||||
@ -1681,7 +1681,7 @@ until the program ends. To avoid this calls to @code{fsync} should be
|
||||
protected using cancelation handlers.
|
||||
@c ref pthread_cleanup_push / pthread_cleanup_pop
|
||||
|
||||
The return value of the function is zero if no error occured. Otherwise
|
||||
The return value of the function is zero if no error occurred. Otherwise
|
||||
it is @math{-1} and the global variable @var{errno} is set to the
|
||||
following values:
|
||||
@table @code
|
||||
@ -1714,7 +1714,7 @@ required by @code{fdatasyn}.
|
||||
|
||||
The prototype for @code{fdatasync} is in @file{unistd.h}.
|
||||
|
||||
The return value of the function is zero if no error occured. Otherwise
|
||||
The return value of the function is zero if no error occurred. Otherwise
|
||||
it is @math{-1} and the global variable @var{errno} is set to the
|
||||
following values:
|
||||
@table @code
|
||||
@ -1745,7 +1745,7 @@ userlevel. In the latter case it might be necessary to link applications
|
||||
with the thread library @file{libpthread} in addition to @file{librt}.
|
||||
|
||||
All AIO operations operate on files which were opened previously. There
|
||||
might be arbitrary many operations for one file running. The
|
||||
might be arbitrarily many operations for one file running. The
|
||||
asynchronous I/O operations are controlled using a data structure named
|
||||
@code{struct aiocb} (@dfn{AIO control block}). It is defined in
|
||||
@file{aio.h} as follows.
|
||||
@ -1873,7 +1873,7 @@ operation terminates. If the @code{sigev_notify} element is
|
||||
@code{SIGEV_NONE} no notification is send. If it is @code{SIGEV_SIGNAL}
|
||||
the signal determined by @code{sigev_signo} is send. Otherwise
|
||||
@code{sigev_notify} must be @code{SIGEV_THREAD} in which case a thread
|
||||
which starts executing the function pointeed to by
|
||||
which starts executing the function pointed to by
|
||||
@code{sigev_notify_function}.
|
||||
|
||||
@item int aio_lio_opcode
|
||||
@ -1938,7 +1938,7 @@ might also be signaled asynchronously.
|
||||
@item EINVAL
|
||||
The @code{aiocbp->aio_offset} or @code{aiocbp->aio_reqpiro} value is
|
||||
invalid. This condition need not be recognized before enqueueing the
|
||||
request and so this error might also be signaled asynchrously.
|
||||
request and so this error might also be signaled asynchronously.
|
||||
@end table
|
||||
|
||||
In the case @code{aio_read} returns zero the current status of the
|
||||
@ -2422,7 +2422,7 @@ For requests which were successfully canceled the normal notification
|
||||
about the termination of the request should take place. I.e., depending
|
||||
on the @code{struct sigevent} object which controls this, nothing
|
||||
happens, a signal is sent or a thread is started. If the request cannot
|
||||
be canceled it terminates the usual way after performing te operation.
|
||||
be canceled it terminates the usual way after performing the operation.
|
||||
|
||||
After a request is successfully canceled a call to @code{aio_error} with
|
||||
a reference to this request as the parameter will return
|
||||
|
@ -49,7 +49,7 @@ Which of the three versions of a function should be used depends on the
|
||||
situation. For most calculations, the @code{float} functions are the
|
||||
fastest. On the other hand, the @code{long double} functions have the
|
||||
highest precision. @code{double} is somewhere in between. It is
|
||||
usually wise to pick the narrowest type that can accomodate your data.
|
||||
usually wise to pick the narrowest type that can accommodate your data.
|
||||
Not all machines have a distinct @code{long double} type; it may be the
|
||||
same as @code{double}.
|
||||
|
||||
@ -1655,7 +1655,7 @@ Using any of the reentrant functions of this family now will
|
||||
automatically initialize the random number generator to the default
|
||||
values for the state and the parameters of the congruential formula.
|
||||
|
||||
The other possibility is too use any of the functions which explicitely
|
||||
The other possibility is too use any of the functions which explicitly
|
||||
initialize the buffer. Though it might be obvious how to initialize the
|
||||
buffer from the data given as parameter from the function it is highly
|
||||
recommended to use these functions since the result might not always be
|
||||
@ -1712,8 +1712,8 @@ programs.
|
||||
@section Is Fast Code or Small Code preferred?
|
||||
@cindex Optimization
|
||||
|
||||
If an application uses many floating point function it is often the case
|
||||
that the costs for the function calls itselfs are not neglectable.
|
||||
If an application uses many floating point functions, it is often the case
|
||||
that the costs of the function calls themselves are not negligible.
|
||||
Modern processor implementation often can execute the operation itself
|
||||
very fast but the call means a disturbance of the control flow.
|
||||
|
||||
@ -1721,17 +1721,17 @@ For this reason the GNU C Library provides optimizations for many of the
|
||||
frequently used math functions. When the GNU CC is used and the user
|
||||
activates the optimizer several new inline functions and macros get
|
||||
defined. These new functions and macros have the same names as the
|
||||
library function and so get used instead of the later. In case of
|
||||
library function and so get used instead of the latter. In case of
|
||||
inline functions the compiler will decide whether it is reasonable to
|
||||
use the inline function and this decision is usually correct.
|
||||
|
||||
For the generated code this means that no calls to the library functions
|
||||
are necessary. This increases the speed significantly. But the
|
||||
drawback is that the code size increases and this increase is not always
|
||||
neglectable.
|
||||
negligible.
|
||||
|
||||
The speed increase has one drawback: the inline functions might not set
|
||||
@code{errno} and might not have the same precission as the library
|
||||
@code{errno} and might not have the same precision as the library
|
||||
functions.
|
||||
|
||||
In cases where the inline functions and macros are not wanted the symbol
|
||||
|
@ -446,7 +446,7 @@ more time to minimize the wasted space.
|
||||
|
||||
@end ignore
|
||||
|
||||
As apposed to other versions, the @code{malloc} in GNU libc does not
|
||||
As opposed to other versions, the @code{malloc} in GNU libc 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 for all
|
||||
@ -636,7 +636,7 @@ variable @code{MALLOC_CHECK_}. When @code{MALLOC_CHECK_} is set, a
|
||||
special (less efficient) implementation is used which is designed to be
|
||||
tolerant against simple errors, such as double calls of @code{free} with
|
||||
the same argument, or overruns of a single byte (off-by-one bugs). Not
|
||||
all such errors can be proteced against, however, and memory leaks can
|
||||
all such errors can be protected against, however, and memory leaks can
|
||||
result. If @code{MALLOC_CHECK_} is set to @code{0}, any detected heap
|
||||
corruption is silently ignored; if set to @code{1}, a diagnostic is
|
||||
printed on @code{stderr}; if set to @code{2}, @code{abort} is called
|
||||
@ -645,7 +645,7 @@ much later, and the true cause for the problem is then very hard to
|
||||
track down.
|
||||
|
||||
So, what's the difference between using @code{MALLOC_CHECK_} and linking
|
||||
with @samp{-lmcheck}? @code{MALLOC_CHECK_} is orthognal with respect to
|
||||
with @samp{-lmcheck}? @code{MALLOC_CHECK_} is orthogonal with respect to
|
||||
@samp{-lmcheck}. @samp{-lmcheck} has been added for backward
|
||||
compatibility. Both @code{MALLOC_CHECK_} and @samp{-lmcheck} should
|
||||
uncover the same bugs - but using @code{MALLOC_CHECK_} you don't need to
|
||||
@ -931,7 +931,7 @@ 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
|
||||
simple means to detect sich leaks and provide some information to find
|
||||
simple means to detect such leaks and provide 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
|
||||
penalties if the program is compiled in preparation of the debugging if
|
||||
@ -974,7 +974,7 @@ systems. The prototype can be found in @file{mcheck.h}.
|
||||
@comment GNU
|
||||
@deftypefun void muntrace (void)
|
||||
The @code{muntrace} function can be called after @code{mtrace} was used
|
||||
to enable tracing the @code{malloc} calls. If no (succesful) call of
|
||||
to enable tracing the @code{malloc} calls. If no (successful) call of
|
||||
@code{mtrace} was made @code{muntrace} does nothing.
|
||||
|
||||
Otherwise it deinstalls the handlers for @code{malloc}, @code{realloc},
|
||||
@ -1110,11 +1110,11 @@ No memory leaks.
|
||||
|
||||
In this case the program @code{tst-mtrace} was run and it produced a
|
||||
trace file @file{log}. The message printed by @code{mtrace} shows there
|
||||
are no problems with the code, all allocated memory was freed
|
||||
are no problems with the code: all allocated memory was freed
|
||||
afterwards.
|
||||
|
||||
If we call @code{mtrace} on the example trace given above we would get a
|
||||
different outout:
|
||||
If we call @code{mtrace} on the example trace given above we would get
|
||||
different output:
|
||||
|
||||
@example
|
||||
drepper$ mtrace errlog
|
||||
|
@ -220,13 +220,13 @@ translation actually happened must look like this:
|
||||
@end smallexample
|
||||
|
||||
@noindent
|
||||
When an error occured the global variable @var{errno} is set to
|
||||
When an error occurred the global variable @var{errno} is set to
|
||||
|
||||
@table @var
|
||||
@item EBADF
|
||||
The catalog does not exist.
|
||||
@item ENOMSG
|
||||
The set/message ttuple does not name an existing element in the
|
||||
The set/message tuple does not name an existing element in the
|
||||
message catalog.
|
||||
@end table
|
||||
|
||||
@ -276,7 +276,7 @@ all @var{string} arguments should be written in the same language.
|
||||
|
||||
It is somewhat uncomfortable to write a program using the @code{catgets}
|
||||
functions if no supporting functionality is available. Since each
|
||||
set/message number tuple must be unique the programmer must keep lists
|
||||
set/message number tuple must be unique, the programmer must keep lists
|
||||
of the messages at the same time the code is written. And the work
|
||||
between several people working on the same project must be coordinated.
|
||||
We will see some how these problems can be relaxed a bit (@pxref{Common
|
||||
@ -722,7 +722,7 @@ Hallo, Welt!
|
||||
|
||||
The call of the @code{gencat} program creates the missing header file
|
||||
@file{msgnrs.h} as well as the message catalog binary. The former is
|
||||
used in the compilation of @file{hello.c} while the later is placed in a
|
||||
used in the compilation of @file{hello.c} while the latter is placed in a
|
||||
directory in which the @code{catopen} function will try to locate it.
|
||||
Please check the @code{LC_ALL} environment variable and the default path
|
||||
for @code{catopen} presented in the description above.
|
||||
@ -816,7 +816,7 @@ history of the function and does not reflect the way the function should
|
||||
be used.
|
||||
|
||||
Please note that above we wrote ``message catalogs'' (plural). This is
|
||||
a speciality of the GNU implementation of these functions and we will
|
||||
a specialty of the GNU implementation of these functions and we will
|
||||
say more about this when we talk about the ways message catalogs are
|
||||
selected (@pxref{Locating gettext catalog}).
|
||||
|
||||
@ -939,7 +939,7 @@ Locate the set of message catalogs. There are a number of files for
|
||||
different languages and which all belong to the package. Usually they
|
||||
are all stored in the filesystem below a certain directory.
|
||||
|
||||
There can be arbitrary many packages installed and they can follow
|
||||
There can be arbitrarily many packages installed and they can follow
|
||||
different guidelines for the placement of their files.
|
||||
|
||||
@item
|
||||
@ -987,7 +987,7 @@ be based on this.
|
||||
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
|
||||
separate domain. It is possible to use in one program arbitrarily many
|
||||
domains at the same time. E.g., the GNU C Library 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
|
||||
@ -1296,10 +1296,10 @@ translated. S/He will simply wrap the translatable string in calls to
|
||||
program has a lot of option which help to customize the output or do
|
||||
help to understand the input better.
|
||||
|
||||
Other programs help to manage development cycle when new messages appear
|
||||
Other programs help to the manage development cycle when new messages appear
|
||||
in the source files or when a new translation of the messages appear.
|
||||
here it should only be noted that using all the tools in GNU gettext it
|
||||
is possible to @emph{completely} automize the handling of message
|
||||
catalog. Beside marking the translatable string in the source code and
|
||||
generating the translations the developers do not have anything to do
|
||||
themself.
|
||||
Here it should only be noted that using all the tools in GNU gettext it
|
||||
is possible to @emph{completely} automate the handling of message
|
||||
catalogs. Beside marking the translatable string in the source code and
|
||||
generating the translations the developers do not have to do anything
|
||||
themselves.
|
||||
|
@ -267,7 +267,7 @@ 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
|
||||
interface which provide a similar interface but which allow to keep
|
||||
arbitrary many hashing tables.
|
||||
arbitrarily many hashing tables.
|
||||
|
||||
It is possible to use more than one hashing table in the program run if
|
||||
the former table is first destroyed by a call to @code{hdestroy}.
|
||||
@ -390,7 +390,7 @@ entry in the table is not the return value of the functions. It is
|
||||
returned by storing it in a pointer variables pointed to by the
|
||||
@var{retval} parameter. The return value of the function is an integer
|
||||
value indicating success if it is non-zero and failure if it is zero.
|
||||
In the later case the global variable @var{errno} signals the reason for
|
||||
In the latter case the global variable @var{errno} signals the reason for
|
||||
the failure.
|
||||
|
||||
@table @code
|
||||
|
@ -1772,7 +1772,7 @@ that the status cannot change in the middle of accessing it. Once
|
||||
@code{p->have_status} is set, it means that the child process is stopped
|
||||
or terminated, and in either case, it cannot stop or terminate again
|
||||
until the program has taken notice. @xref{Atomic Usage}, for more
|
||||
information about coping with interruptions during accessings of a
|
||||
information about coping with interruptions during accesses of a
|
||||
variable.
|
||||
|
||||
Here is another way you can test whether the handler has run since the
|
||||
|
@ -676,9 +676,9 @@ namespace.
|
||||
This section describes the details of the protocols and socket naming
|
||||
conventions used in the Internet namespace.
|
||||
|
||||
Originaly the Internet namespace used only IP version 4 (IPv4). With
|
||||
Originally the Internet namespace used only IP version 4 (IPv4). With
|
||||
the growing number of hosts on the Internet, a new protocol with a
|
||||
larger address space was neccessary: IP version 6 (IPv6). IPv6
|
||||
larger address space was necessary: IP version 6 (IPv6). IPv6
|
||||
introduces besides 128bit addresses (IPv4 has 32bit addresses) also
|
||||
other features and will eventually replace IPv4.
|
||||
|
||||
@ -835,7 +835,7 @@ Historically these are divided into two parts, a @dfn{network number} and a
|
||||
mid-1990s classless address were introduced which changed the
|
||||
behaviour. Since some functions implicitly expect the old definitions,
|
||||
we first describe the class based network and will then describe
|
||||
classless addresses. IPv6 uses only classless adresses and therefore
|
||||
classless addresses. IPv6 uses only classless addresses and therefore
|
||||
the following paragraphs don't apply.
|
||||
|
||||
The class based IPv4 network number consists of the first one, two or
|
||||
@ -904,10 +904,10 @@ radix is assumed.
|
||||
|
||||
IPv4 addresses (and IPv6 addresses also) are now considered as
|
||||
classless. The distinction between classes A, B, and C can be ignored.
|
||||
Instead a IPv4 host adddress consists of a 32-bit address and a 32-bit
|
||||
Instead a IPv4 host address consists of a 32-bit address and a 32-bit
|
||||
mask. The mask contains bits of 1 for the network part and bits of 0
|
||||
for the host part. The 1-bits are contigous from the leftmost bit, the
|
||||
0-bits are contigous from the rightmost bit so that the netmask can also
|
||||
for the host part. The 1-bits are contiguous from the leftmost bit, the
|
||||
0-bits are contiguous from the rightmost bit so that the netmask can also
|
||||
be written as a prefix length of bits of 1. Classes A, B and C are just
|
||||
special cases of this general rule. For example, class A addresses have
|
||||
a netmask of @samp{255.0.0.0} or a prefix length of 8.
|
||||
|
@ -1303,7 +1303,7 @@ numbers are represented is the form
|
||||
@w{[@code{-}]@code{0x}@var{h}@code{.}@var{hhh}@code{p}[@code{+}|@code{-}]@var{dd}}.
|
||||
At the left of the decimal-point character exactly one digit is print.
|
||||
This character is only @code{0} if the number is denormalized.
|
||||
Otherwise the value is unspecified; it is implemention dependent how many
|
||||
Otherwise the value is unspecified; it is implementation dependent how many
|
||||
bits are used. The number of hexadecimal digits on the right side of
|
||||
the decimal-point character is equal to the precision. If the precision
|
||||
is zero it is determined to be large enough to provide an exact
|
||||
@ -4234,7 +4234,7 @@ is incorrect.
|
||||
There are two environment variables which influence the behaviour of
|
||||
@code{fmtmsg}. The first is @code{MSGVERB}. It is used to control the
|
||||
output actually happening on standard error (@emph{not} the console
|
||||
output). Each of the five fields can explicitely be enabled. To do
|
||||
output). Each of the five fields can be explicitly enabled. To do
|
||||
this the user has to put the @code{MSGVERB} variable with a format like
|
||||
the following in the environment before calling the @code{fmtmsg} function
|
||||
the first time:
|
||||
@ -4329,7 +4329,7 @@ The second call to @code{fmtmsg} illustrates a use of this function how
|
||||
it usually happens on System V systems which heavily use this function.
|
||||
It might be worth a thought to follow the scheme used in System V
|
||||
systems so we give a short explanation here. The value of the
|
||||
@var{label} field (@code{UX:cat}) says that the error occured in the
|
||||
@var{label} field (@code{UX:cat}) says that the error occurred in the
|
||||
Unix program @code{cat}. The explanation of the error follows and the
|
||||
value for the @var{action} parameter is @code{"refer to manual"}. One
|
||||
could me more specific here, if needed. The @var{tag} field contains,
|
||||
|
@ -491,7 +491,7 @@ common example:
|
||||
@cindex __va_copy
|
||||
@cindex va_copy
|
||||
@smallexample
|
||||
/* @r{This function concats arbitrary many strings. The last}
|
||||
/* @r{This function concatenates arbitrarily many strings. The last}
|
||||
@r{parameter must be @code{NULL}.} */
|
||||
char *
|
||||
concat (const char *str, ...)
|
||||
@ -536,7 +536,7 @@ bytes for the end of the string so that we can append the next string.
|
||||
For all strings in total the comparisons necessary to find the end of
|
||||
the intermediate results sums up to 5500! If we combine the copying
|
||||
with the search for the allocation we can write this function more
|
||||
efficent:
|
||||
efficient:
|
||||
|
||||
@smallexample
|
||||
char *
|
||||
@ -1563,7 +1563,7 @@ the same elements, which is returned in @var{argz} and @var{argz_len}.
|
||||
@deftypefun {error_t} argz_create_sep (const char *@var{string}, int @var{sep}, char **@var{argz}, size_t *@var{argz_len})
|
||||
The @code{argz_create_sep} function converts the null-terminated string
|
||||
@var{string} into an argz vector (returned in @var{argz} and
|
||||
@var{argz_len}) by splitting it into elements at every occurance of the
|
||||
@var{argz_len}) by splitting it into elements at every occurrence of the
|
||||
character @var{sep}.
|
||||
@end deftypefun
|
||||
|
||||
@ -1613,7 +1613,7 @@ argz vector @code{*@var{argz}}, and updates @code{*@var{argz}} and
|
||||
@comment GNU
|
||||
@deftypefun {error_t} argz_add_sep (char **@var{argz}, size_t *@var{argz_len}, const char *@var{str}, int @var{delim})
|
||||
The @code{argz_add_sep} function is similar to @code{argz_add}, but
|
||||
@var{str} is split into separate elements in the result at occurances of
|
||||
@var{str} is split into separate elements in the result at occurrences of
|
||||
the character @var{delim}. This is useful, for instance, for
|
||||
adding the components of a Unix search path to an argz vector, by using
|
||||
a value of @code{':'} for @var{delim}.
|
||||
@ -1688,7 +1688,7 @@ invariant is maintained for argz vectors created by the functions here.
|
||||
@comment argz.h
|
||||
@comment GNU
|
||||
@deftypefun error_t argz_replace (@w{char **@var{argz}, size_t *@var{argz_len}}, @w{const char *@var{str}, const char *@var{with}}, @w{unsigned *@var{replace_count}})
|
||||
Replace any occurances of the string @var{str} in @var{argz} with
|
||||
Replace any occurrences of the string @var{str} in @var{argz} with
|
||||
@var{with}, reallocating @var{argz} as necessary. If
|
||||
@var{replace_count} is non-zero, @code{*@var{replace_count}} will be
|
||||
incremented by number of replacements performed.
|
||||
|
@ -420,7 +420,7 @@ to rely on these macros but to be consistent here is the list:
|
||||
@vtable @code
|
||||
@item MNTOPT_DEFAULTS
|
||||
Expands to @code{"defaults"}. This option should be used alone since it
|
||||
indicates all values for the custumizable values are chosen to be the
|
||||
indicates all values for the customizable values are chosen to be the
|
||||
default.
|
||||
@item MNTOPT_RO
|
||||
Expands to @code{"ro"}. See the @code{FSTAB_RO} value, it means the
|
||||
|
@ -104,7 +104,7 @@ around 36 minutes.
|
||||
@deftypevr Macro int CLOCKS_PER_SEC
|
||||
The value of this macro is the number of clock ticks per second measured
|
||||
by the @code{clock} function. POSIX requires that this value is one
|
||||
million independend of the actual resolution.
|
||||
million independent of the actual resolution.
|
||||
@end deftypevr
|
||||
|
||||
@comment time.h
|
||||
@ -552,7 +552,7 @@ Zone Functions}.
|
||||
|
||||
Using the @code{localtime} function is a big problem in multi-threaded
|
||||
programs. The result is returned in a static buffer and this is used in
|
||||
all threads. POSIX.1c introduced a varient of this function.
|
||||
all threads. POSIX.1c introduced a variant of this function.
|
||||
|
||||
@comment time.h
|
||||
@comment POSIX.1c
|
||||
@ -1892,7 +1892,7 @@ This is the estimated error, measured in microseconds. This value can
|
||||
be set using bit @code{MOD_ESTERROR}.
|
||||
|
||||
@item int status
|
||||
This valiable reflects the various states of the clock machinery. There
|
||||
This variable reflects the various states of the clock machinery. There
|
||||
are symbolic constants for the significant bits, starting with
|
||||
@code{STA_}. Some of these flags can be updated using the
|
||||
@code{MOD_STATUS} bit.
|
||||
@ -1930,7 +1930,7 @@ This value represents the median filtered dispersion of the PPS
|
||||
frequency in scaled PPM.
|
||||
|
||||
@item long int jitcnt
|
||||
This counter represents the numer of pulses where the jitter exceeded
|
||||
This counter represents the number of pulses where the jitter exceeded
|
||||
the allowed maximum @code{MAXTIME}.
|
||||
|
||||
@item long int calcnt
|
||||
|
@ -1482,7 +1482,7 @@ pointed to by the elements of the result structure.
|
||||
If a user with ID @var{uid} is found, the pointer returned in
|
||||
@var{result} points to the record which contains the wanted data (i.e.,
|
||||
@var{result} contains the value @var{result_buf}). If no user is found
|
||||
or if an error occured, the pointer returned in @var{result} is a null
|
||||
or if an error occurred, the pointer returned in @var{result} is a null
|
||||
pointer. The function returns zero or an error code. If the buffer
|
||||
@var{buffer} is too small to contain all the needed information, the
|
||||
error code @code{ERANGE} is returned and @var{errno} is set to
|
||||
@ -1695,7 +1695,7 @@ pointed to by the elements of the result structure.
|
||||
If a group with ID @var{gid} is found, the pointer returned in
|
||||
@var{result} points to the record which contains the wanted data (i.e.,
|
||||
@var{result} contains the value @var{result_buf}). If no group is found
|
||||
or if an error occured, the pointer returned in @var{result} is a null
|
||||
or if an error occurred, the pointer returned in @var{result} is a null
|
||||
pointer. The function returns zero or an error code. If the buffer
|
||||
@var{buffer} is too small to contain all the needed information, the
|
||||
error code @code{ERANGE} is returned and @var{errno} is set to
|
||||
|
@ -95,7 +95,7 @@
|
||||
between the two kinds of NaNs as result.
|
||||
|
||||
Inline functions: Inlining functions should give an improvement in
|
||||
speed - but not in precission. The inlined functions return
|
||||
speed - but not in precision. The inlined functions return
|
||||
reasonable values for a reasonable range of input values. The
|
||||
result is not necessarily correct for all values and exceptions are
|
||||
not correctly raised in all cases. Problematic input and return
|
||||
@ -6301,7 +6301,7 @@ main (int argc, char *argv[])
|
||||
noTests, noExcTests);
|
||||
if (noErrors)
|
||||
{
|
||||
printf (" %d errors occured.\n", noErrors);
|
||||
printf (" %d errors occurred.\n", noErrors);
|
||||
exit (1);
|
||||
}
|
||||
printf (" All tests passed successfully.\n");
|
||||
|
@ -392,7 +392,7 @@ main (void)
|
||||
|
||||
if (count_errors)
|
||||
{
|
||||
printf ("\n%d errors occured.\n", count_errors);
|
||||
printf ("\n%d errors occurred.\n", count_errors);
|
||||
exit (1);
|
||||
}
|
||||
printf ("\n All tests passed successfully.\n");
|
||||
|
@ -174,7 +174,7 @@ nscd_gethst_r (const char *key, size_t keylen, request_type type,
|
||||
char *ignore;
|
||||
int n;
|
||||
|
||||
/* A first check whether the buffer is sufficently large is possible. */
|
||||
/* A first check whether the buffer is sufficiently large is possible. */
|
||||
/* Now allocate the buffer the array for the group members. We must
|
||||
align the pointer and the base of the h_addr_list pointers. */
|
||||
align1 = ((__alignof__ (char *) - (cp - ((char *) 0)))
|
||||
|
@ -41,7 +41,7 @@
|
||||
#include "nss.h"
|
||||
|
||||
/*
|
||||
The following define is neccessary for glibc 2.0.6
|
||||
The following define is necessary for glibc 2.0.6
|
||||
*/
|
||||
#ifndef INET6_ADDRSTRLEN
|
||||
# define INET6_ADDRSTRLEN 46
|
||||
@ -361,9 +361,9 @@ main (void)
|
||||
test_services ();
|
||||
|
||||
if (error_count)
|
||||
printf ("\n %d errors occured!\n", error_count);
|
||||
printf ("\n %d errors occurred!\n", error_count);
|
||||
else
|
||||
printf ("No visible errors occured!\n");
|
||||
printf ("No visible errors occurred!\n");
|
||||
|
||||
exit (error_count);
|
||||
}
|
||||
|
@ -5716,7 +5716,7 @@ regcomp (preg, pattern, cflags)
|
||||
buffer. */
|
||||
if (re_compile_fastmap (preg) == -2)
|
||||
{
|
||||
/* Some error occured while computing the fastmap, just forget
|
||||
/* Some error occurred while computing the fastmap, just forget
|
||||
about it. */
|
||||
free (preg->fastmap);
|
||||
preg->fastmap = NULL;
|
||||
|
@ -38,7 +38,7 @@ sub usage {
|
||||
sub installation_problem {
|
||||
print "The script has found some problems with your installation!\n";
|
||||
print "Please read the FAQ and the README file and check the following:\n";
|
||||
print "- Did you change the gcc specs file (neccessary after upgrading from\n";
|
||||
print "- Did you change the gcc specs file (necessary after upgrading from\n";
|
||||
print " Linux libc5)?\n";
|
||||
print "- Are there any symbolic links of the form libXXX.so to old libraries?\n";
|
||||
print " Links like libm.so -> libm.so.5 (where libm.so.5 is an old library) are wrong,\n";
|
||||
|
@ -48,7 +48,7 @@ canonicalize (const char *name, char *resolved)
|
||||
{
|
||||
/* As per Single Unix Specification V2 we must return an error if
|
||||
either parameter is a null pointer. We extend this to allow
|
||||
the RESOLVED parameter be NULL in case the we are expected to
|
||||
the RESOLVED parameter to be NULL in case the we are expected to
|
||||
allocate the room for the return value. */
|
||||
__set_errno (EINVAL);
|
||||
return NULL;
|
||||
|
@ -155,7 +155,7 @@ fmtmsg (long int classification, const char *label, int severity,
|
||||
do_action ? action : "",
|
||||
do_action && do_tag ? " " : "",
|
||||
do_tag ? tag : "") == EOF)
|
||||
/* Oh, oh. An error occured during the output. */
|
||||
/* Oh, oh. An error occurred during the output. */
|
||||
result = MM_NOMSG;
|
||||
}
|
||||
|
||||
|
@ -43,7 +43,7 @@ str_append (char **to, size_t *to_len, const char *buf, const size_t buf_len)
|
||||
}
|
||||
}
|
||||
|
||||
/* Replace any occurances of the string STR in ARGZ with WITH, reallocating
|
||||
/* Replace any occurrences of the string STR in ARGZ with WITH, reallocating
|
||||
ARGZ as necessary. If REPLACE_COUNT is non-zero, *REPLACE_COUNT will be
|
||||
incremented by number of replacements performed. */
|
||||
error_t
|
||||
|
@ -126,7 +126,7 @@ extern error_t argz_insert __P ((char **__restrict __argz,
|
||||
char *__restrict __before,
|
||||
__const char *__restrict __entry));
|
||||
|
||||
/* Replace any occurances of the string STR in ARGZ with WITH, reallocating
|
||||
/* Replace any occurrences of the string STR in ARGZ with WITH, reallocating
|
||||
ARGZ as necessary. If REPLACE_COUNT is non-zero, *REPLACE_COUNT will be
|
||||
incremented by number of replacements performed. */
|
||||
extern error_t __argz_replace (char **__restrict __argz,
|
||||
|
@ -37,7 +37,7 @@
|
||||
to make sure we don't get redefinitions.
|
||||
|
||||
We must use here macros instead of inline functions since the
|
||||
trick won't work with the later. */
|
||||
trick won't work with the latter. */
|
||||
|
||||
#ifndef __STRING_INLINE
|
||||
# ifdef __cplusplus
|
||||
|
@ -511,7 +511,7 @@ glob (pattern, flags, errfunc, pglob)
|
||||
#endif /* __MSDOS__ || WINDOWS32 */
|
||||
if (filename == NULL)
|
||||
{
|
||||
/* This can mean two things: a simple name or "~name". The later
|
||||
/* This can mean two things: a simple name or "~name". The latter
|
||||
case is nothing but a notation for a directory. */
|
||||
if ((flags & (GLOB_TILDE|GLOB_TILDE_CHECK)) && pattern[0] == '~')
|
||||
{
|
||||
|
@ -66,7 +66,7 @@ __libc_lock_define_initialized (static, envlock)
|
||||
#endif
|
||||
|
||||
/* In the GNU C library implementation we try to be more clever and
|
||||
allow arbitrary many changes of the environment given that the used
|
||||
allow arbitrarily many changes of the environment given that the used
|
||||
values are from a small set. Outside glibc this will eat up all
|
||||
memory after a while. */
|
||||
#if defined _LIBC || (defined HAVE_SEARCH_H && defined HAVE_TSEARCH \
|
||||
|
@ -53,7 +53,7 @@ ENTRY (memcmp)
|
||||
or not depending on last subtraction. */
|
||||
|
||||
/* At this point %eax == 0, if the byte of block #1 was bigger, and
|
||||
0xffffffff if the last byte of block #2 was bigger. The later
|
||||
0xffffffff if the last byte of block #2 was bigger. The latter
|
||||
case is already correct but the former needs a little adjustment.
|
||||
Note that the following operation does not change 0xffffffff. */
|
||||
orb $1, %al /* Change 0 to 1. */
|
||||
|
@ -1,5 +1,5 @@
|
||||
/* Pseudo implementation of waitid.
|
||||
Copyright (C) 1997, 1998 Free Software Foundation, Inc.
|
||||
Copyright (C) 1997, 1998, 2000 Free Software Foundation, Inc.
|
||||
This file is part of the GNU C Library.
|
||||
Contributed by Zack Weinberg <zack@rabi.phys.columbia.edu>, 1997.
|
||||
|
||||
@ -79,7 +79,7 @@ waitid (idtype, id, infop, options)
|
||||
{
|
||||
/* The WHOHANG bit in OPTIONS is set and there are children available
|
||||
but none has a status for us. The XPG docs do not mention this
|
||||
case so we clear the `siginfo_t' struct and return succesfully. */
|
||||
case so we clear the `siginfo_t' struct and return successfully. */
|
||||
infop->si_signo = 0;
|
||||
infop->si_code = 0;
|
||||
return 0;
|
||||
|
@ -513,7 +513,7 @@ tz_compute (tm)
|
||||
|| ! compute_change (&tz_rules[1], 1900 + tm->tm_year))
|
||||
return 0;
|
||||
/* We have to distinguish between northern and southern hemisphere.
|
||||
For the later the daylight saving time ends in the next year.
|
||||
For the latter the daylight saving time ends in the next year.
|
||||
It is easier to detect this after first computing the time for the
|
||||
wrong year since now we simply can compare the times to switch. */
|
||||
if (tz_rules[0].change > tz_rules[1].change
|
||||
|
Loading…
Reference in New Issue
Block a user