2000-03-09 Martin Buchholz <martin@xemacs.org>
* sysdeps/unix/sysv/linux/alpha/syscall.S: * manual/message.texi (Using gettextized software): * manual/message.texi (Message Translation): Doc Fixes. * manual/filesys.texi (File Size): * manual/charset.texi (glibc iconv Implementation): * locale/programs/ld-collate.c (collate_output): * iconv/gconv_db.c (find_derivation): * manual/install.texi: * manual/search.texi (Hash Search Function): * manual/stdio.texi (Output Conversion Syntax): * FAQ.in: * config.h.in: * sysdeps/generic/dl-sysdep.c: Doc Fixes. `allows to' is not correct English. * elf/rtld.c: Doc fixes. * manual/creature.texi (Feature Test Macros): Doc fixes. * manual/memory.texi (Hooks for Malloc): Doc Fixes. * manual/filesys.texi (Working Directory): Check for ERANGE to avoid infloop.
This commit is contained in:
Andreas Jaeger
parent
f25da8d01f
commit
e8b1163ed0
2
FAQ.in
2
FAQ.in
|
|
@ -865,7 +865,7 @@ Note that I have at this point no information about any other platform.
|
|||
{AJ} This is at first a kernel issue. The kernel defines limits with
|
||||
OPEN_MAX the number of simultaneous open files and with FD_SETSIZE the
|
||||
number of used file descriptors. You need to change these values in your
|
||||
kernel and recompile the kernel so that the kernel allows to use more open
|
||||
kernel and recompile the kernel so that the kernel allows more open
|
||||
files. You don't necessarily need to recompile the GNU C library since the
|
||||
only place where OPEN_MAX and FD_SETSIZE is really needed in the library
|
||||
itself is the size of fd_set which is used by select.
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@
|
|||
/* Linux specific: minimum supported kernel version. */
|
||||
#undef __LINUX_KERNEL_VERSION
|
||||
|
||||
/* An extension in gcc 2.96 and up allows to substract the values of two
|
||||
/* An extension in gcc 2.96 and up allows the subtraction of two
|
||||
local labels. */
|
||||
#undef HAVE_SUBTRACT_LOCAL_LABELS
|
||||
|
||||
|
|
|
|||
|
|
@ -454,7 +454,7 @@ of this helper program; chances are you did not intend to run this program.\n\
|
|||
\n\
|
||||
--list list all dependencies and how they are resolved\n\
|
||||
--verify verify that given object really is a dynamically linked\n\
|
||||
object we get handle\n\
|
||||
object we can handle\n\
|
||||
--library-path PATH use given PATH instead of content of the environment\n\
|
||||
variable LD_LIBRARY_PATH\n\
|
||||
--inhibit-rpath LIST ignore RUNPATH and RPATH information in object names\n\
|
||||
|
|
|
|||
|
|
@ -359,8 +359,8 @@ find_derivation (const char *toset, const char *toset_expand,
|
|||
one with the lower costs. Otherwise add the new charset at the
|
||||
end.
|
||||
|
||||
The module database is organized in a tree form which allows to
|
||||
search for prefixes. So we search for the first entry with a
|
||||
The module database is organized in a tree form which allows
|
||||
searching for prefixes. So we search for the first entry with a
|
||||
matching prefix and any other matching entry can be found from
|
||||
this place. */
|
||||
struct gconv_module *node = __gconv_modules_db;
|
||||
|
|
|
|||
|
|
@ -2012,8 +2012,8 @@ collate_output (struct localedef_t *locale, struct charmap_t *charmap,
|
|||
{
|
||||
/* The entries in the list are sorted by length and then
|
||||
alphabetically. This is the order in which we will add the
|
||||
elements to the collation table. This allows to simply
|
||||
walk the table in sequence and stop at the first matching
|
||||
elements to the collation table. This allows simply walking
|
||||
the table in sequence and stopping at the first matching
|
||||
entry. Since the longer sequences are coming first in the
|
||||
list they have the possibility to match first, just as it
|
||||
has to be. In the worst case we are walking to the end of
|
||||
|
|
|
|||
|
|
@ -2369,7 +2369,7 @@ which must appear exactly once for an entire text. If a number of
|
|||
must add the prolog. But since there is no communication between the
|
||||
different calls of @code{mbsrtowcs} the conversion functions have no
|
||||
possibility to find this out. The situation is different for sequences
|
||||
of @code{iconv} calls since the handle allows to access the needed
|
||||
of @code{iconv} calls since the handle allows access to the needed
|
||||
information.
|
||||
|
||||
This element is mostly used together with @code{__invocation_counter} in
|
||||
|
|
|
|||
|
|
@ -148,15 +148,15 @@ This macro was introduced as part of the Large File Support extension (LFS).
|
|||
@comment (NONE)
|
||||
@comment X/Open
|
||||
@defvr Macro _LARGEFILE64_SOURCE
|
||||
If you define this macro an additional set of function gets available
|
||||
which enables to use on @w{32 bit} systems to use files of sizes beyond
|
||||
If you define this macro an additional set of function is made available
|
||||
which enables @w{32 bit} systems to use files of sizes beyond
|
||||
the usual limit of 2GB. This interface is not available if the system
|
||||
does not support files that large. On systems where the natural file
|
||||
size limit is greater than 2GB (i.e., on @w{64 bit} systems) the new
|
||||
functions are identical to the replaced functions.
|
||||
|
||||
The new functionality is made available by a new set of types and
|
||||
functions which replace existing. The names of these new objects
|
||||
functions which replace the existing ones. The names of these new objects
|
||||
contain @code{64} to indicate the intention, e.g., @code{off_t}
|
||||
vs. @code{off64_t} and @code{fseeko} vs. @code{fseeko64}.
|
||||
|
||||
|
|
@ -168,18 +168,18 @@ not generally used (see @code{_FILE_OFFSET_BITS}.
|
|||
@comment (NONE)
|
||||
@comment X/Open
|
||||
@defvr Macro _FILE_OFFSET_BITS
|
||||
This macro lets decide which file system interface shall be used, one
|
||||
This macro determines which file system interface shall be used, one
|
||||
replacing the other. While @code{_LARGEFILE64_SOURCE} makes the @w{64
|
||||
bit} interface available as an additional interface
|
||||
@code{_FILE_OFFSET_BITS} allows to use the @w{64 bit} interface to
|
||||
@code{_FILE_OFFSET_BITS} allows the @w{64 bit} interface to
|
||||
replace the old interface.
|
||||
|
||||
If @code{_FILE_OFFSET_BITS} is undefined or if it is defined to the
|
||||
value @code{32} nothing changes. The @w{32 bit} interface is used and
|
||||
If @code{_FILE_OFFSET_BITS} is undefined, or if it is defined to the
|
||||
value @code{32}, nothing changes. The @w{32 bit} interface is used and
|
||||
types like @code{off_t} have a size of @w{32 bits} on @w{32 bit}
|
||||
systems.
|
||||
|
||||
If the macro is defined to the value @code{64} the large file interface
|
||||
If the macro is defined to the value @code{64}, the large file interface
|
||||
replaces the old interface. I.e., the functions are not made available
|
||||
under different names as @code{_LARGEFILE64_SOURCE} does. Instead the
|
||||
old function names now reference the new functions, e.g., a call to
|
||||
|
|
@ -233,10 +233,10 @@ get very strange errors at run time.
|
|||
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 that the standardization of the thread safe C library
|
||||
interface still is behind.
|
||||
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
|
||||
Unlike on some other systems, no special version of the C library must be
|
||||
used for linking. There is only one version but while compiling this
|
||||
it must have been specified to compile as thread safe.
|
||||
@end defvr
|
||||
|
|
|
|||
|
|
@ -91,19 +91,18 @@ using only the standard behavior of @code{getcwd}:
|
|||
|
||||
@smallexample
|
||||
char *
|
||||
gnu_getcwd ()
|
||||
gnu_getcwd (size_t size)
|
||||
@{
|
||||
int size = 100;
|
||||
char *buffer = (char *) xmalloc (size);
|
||||
|
||||
while (1)
|
||||
@{
|
||||
char *buffer = (char *) xmalloc (size);
|
||||
char *value = getcwd (buffer, size);
|
||||
if (value != 0)
|
||||
return buffer;
|
||||
size *= 2;
|
||||
if (value == buffer)
|
||||
return value;
|
||||
free (buffer);
|
||||
buffer = (char *) xmalloc (size);
|
||||
if (errno != ERANGE)
|
||||
return value;
|
||||
size *= 2;
|
||||
@}
|
||||
@}
|
||||
@end smallexample
|
||||
|
|
@ -2558,8 +2557,8 @@ The operation was interrupted by a signal.
|
|||
@deftypefun int truncate64 (const char *@var{name}, off64_t @var{length})
|
||||
This function is similar to the @code{truncate} function. The
|
||||
difference is that the @var{length} argument is 64 bits wide even on 32
|
||||
bits machines which allows to handle file with a size up to @math{2^63}
|
||||
bytes.
|
||||
bits machines, which allows the handling of files with sizes up to
|
||||
@math{2^63} bytes.
|
||||
|
||||
When the source file is compiled with @code{_FILE_OFFSET_BITS == 64} on a
|
||||
32 bits machine this function is actually available under the name
|
||||
|
|
@ -2635,8 +2634,8 @@ The operation was interrupted by a signal.
|
|||
@deftypefun int ftruncate64 (int @var{id}, off64_t @var{length})
|
||||
This function is similar to the @code{ftruncate} function. The
|
||||
difference is that the @var{length} argument is 64 bits wide even on 32
|
||||
bits machines which allows to handle file with a size up to @math{2^63}
|
||||
bytes.
|
||||
bits machines which allows the handling of files with sizes up to
|
||||
@math{2^63} bytes.
|
||||
|
||||
When the source file is compiled with @code{_FILE_OFFSET_BITS == 64} on a
|
||||
32 bits machine this function is actually available under the name
|
||||
|
|
|
|||
|
|
@ -52,9 +52,9 @@ GNU Make, and possibly others. @xref{Tools for Compilation}, below.
|
|||
GNU libc can be compiled in the source directory, but we strongly advise to
|
||||
build it in a separate build directory. For example, if you have unpacked
|
||||
the glibc sources in @file{/src/gnu/glibc-2.1.0}, create a directory
|
||||
@file{/src/gnu/glibc-build} to put the object files in. This allows to
|
||||
remove the whole build directory in case an error occurs which is the
|
||||
safest way to get a clean way and should always be done.
|
||||
@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.
|
||||
|
||||
From your object directory, run the shell script @file{configure} found
|
||||
at the top level of the source tree. In the scenario above, you'd type
|
||||
|
|
|
|||
|
|
@ -519,7 +519,7 @@ choices for @var{param}, as defined in @file{malloc.h}, are:
|
|||
|
||||
@table @code
|
||||
@item M_TRIM_THRESHOLD
|
||||
This is the minimum size (in bytes) of the top-most, releaseable chunk
|
||||
This is the minimum size (in bytes) of the top-most, releasable chunk
|
||||
that will cause @code{sbrk} to be called with a negative argument in
|
||||
order to return memory to the system.
|
||||
@item M_TOP_PAD
|
||||
|
|
@ -691,7 +691,7 @@ void *@var{function} (void *@var{ptr}, size_t @var{size}, void *@var{caller})
|
|||
@end smallexample
|
||||
|
||||
The value of @var{caller} is the return address found on the stack when
|
||||
the @code{realloc} function was called. This value allows to trace the
|
||||
the @code{realloc} function was called. This value allows you to trace the
|
||||
memory consumption of the program.
|
||||
@end defvar
|
||||
|
||||
|
|
@ -707,7 +707,7 @@ void @var{function} (void *@var{ptr}, void *@var{caller})
|
|||
@end smallexample
|
||||
|
||||
The value of @var{caller} is the return address found on the stack when
|
||||
the @code{free} function was called. This value allows to trace the
|
||||
the @code{free} function was called. This value allows you to trace the
|
||||
memory consumption of the program.
|
||||
@end defvar
|
||||
|
||||
|
|
@ -887,7 +887,7 @@ This is the total size of memory occupied by chunks handed out by
|
|||
This is the total size of memory occupied by free (not in use) chunks.
|
||||
|
||||
@item int keepcost
|
||||
This is the size of the top-most releaseable chunk that normally
|
||||
This is the size of the top-most releasable chunk that normally
|
||||
borders the end of the heap (i.e. the ``brk'' of the process).
|
||||
|
||||
@end table
|
||||
|
|
@ -994,12 +994,12 @@ nothing is done. The behaviour of @code{malloc} etc. is not changed.
|
|||
For obvious reasons this also happens if the application is installed
|
||||
with the SUID or SGID bit set.
|
||||
|
||||
If the named file is successfully opened @code{mtrace} installs special
|
||||
If the named file is successfully opened, @code{mtrace} installs special
|
||||
handlers for the functions @code{malloc}, @code{realloc}, and
|
||||
@code{free} (@pxref{Hooks for Malloc}). From now on all uses of these
|
||||
@code{free} (@pxref{Hooks for Malloc}). From then on, all uses of these
|
||||
functions are traced and protocolled into the file. There is now of
|
||||
course a speed penalty for all calls to the traced functions so tracing
|
||||
should not be enabled during their normal use.
|
||||
should not be enabled during normal use.
|
||||
|
||||
This function is a GNU extension and generally not available on other
|
||||
systems. The prototype can be found in @file{mcheck.h}.
|
||||
|
|
|
|||
|
|
@ -160,10 +160,10 @@ does this just like it works for @code{printf}.
|
|||
@end table
|
||||
|
||||
|
||||
Using @code{NLSPATH} allows to specify arbitrary directories to be
|
||||
searched for message catalogs while still allowing different languages
|
||||
to be used. If the @code{NLSPATH} environment variable is not set the
|
||||
default value is
|
||||
Using @code{NLSPATH} allows arbitrary directories to be searched for
|
||||
message catalogs while still allowing different languages to be used.
|
||||
If the @code{NLSPATH} environment variable is not set, the default value
|
||||
is
|
||||
|
||||
@smallexample
|
||||
@var{prefix}/share/locale/%L/%N:@var{prefix}/share/locale/%L/LC_MESSAGES/%N
|
||||
|
|
@ -453,7 +453,7 @@ these source files to learn about the file format.
|
|||
|
||||
@cindex gencat
|
||||
The @code{gencat} program is specified in the X/Open standard and the
|
||||
GNU implementation follows this specification and so allows to process
|
||||
GNU implementation follows this specification and so processes
|
||||
all correctly formed input files. Additionally some extension are
|
||||
implemented which help to work in a more reasonable way with the
|
||||
@code{catgets} functions.
|
||||
|
|
@ -1525,13 +1525,13 @@ complete @var{dir_name} is:
|
|||
@end smallexample
|
||||
|
||||
We can use @file{/usr/share} since the @file{.mo} files containing the
|
||||
message catalogs are system independent, all systems can use the same
|
||||
message catalogs are system independent, so all systems can use the same
|
||||
files. If the program executed the @code{bindtextdomain} function for
|
||||
the message domain that is currently handled the @code{dir_name}
|
||||
component is the exactly the value which was given to the function as
|
||||
the second parameter. I.e., @code{bindtextdomain} allows to overwrite
|
||||
the message domain that is currently handled, the @code{dir_name}
|
||||
component is exactly the value which was given to the function as
|
||||
the second parameter. I.e., @code{bindtextdomain} allows overwriting
|
||||
the only system dependent and fixed value to make it possible to
|
||||
address file everywhere in the filesystem.
|
||||
address files anywhere in the filesystem.
|
||||
|
||||
The @var{category} is the name of the locale category which was selected
|
||||
in the program code. For @code{gettext} and @code{dgettext} this is
|
||||
|
|
|
|||
|
|
@ -358,7 +358,7 @@ The @code{hcreate_r} function initializes the object pointed to by
|
|||
So this function is equivalent to the @code{hcreate} function except
|
||||
that the initialized data structure is controlled by the user.
|
||||
|
||||
This allows to have more than once hashing table at one time. The
|
||||
This allows having more than one hashing table at one time. The
|
||||
memory necessary for the @code{struct hsearch_data} object can be
|
||||
allocated dynamically.
|
||||
|
||||
|
|
@ -499,8 +499,8 @@ X/Open specifications.
|
|||
@end deftypefun
|
||||
|
||||
In addition to the function to create and destroy the tree data
|
||||
structure there is another function which allows to apply a function on
|
||||
all elements of the tree. The function must have this type:
|
||||
structure, there is another function which allows you to apply a
|
||||
function to all elements of the tree. The function must have this type:
|
||||
|
||||
@smallexample
|
||||
void __action_fn_t (const void *nodep, VISIT value, int level);
|
||||
|
|
|
|||
|
|
@ -972,10 +972,10 @@ initial @samp{%} character followed in sequence by:
|
|||
@itemize @bullet
|
||||
@item
|
||||
An optional specification of the parameter used for this format.
|
||||
Normally the parameters to the @code{printf} function a assigned to the
|
||||
Normally the parameters to the @code{printf} function are assigned to the
|
||||
formats in the order of appearance in the format string. But in some
|
||||
situations (such as message translation) this is not desirable and this
|
||||
extension allows to specify and explicit parameter to be used.
|
||||
extension allows an explicit parameter to be specified.
|
||||
|
||||
The @var{param-no} part of the format must be an integer in the range of
|
||||
1 to the maximum number of arguments present to the function call. Some
|
||||
|
|
|
|||
|
|
@ -358,8 +358,8 @@ _dl_important_hwcaps (const char *platform, size_t platform_len, size_t *sz,
|
|||
#1: 0, 1, 3 1101
|
||||
#2: 0, 2, 3 1011
|
||||
#3: 0, 3 1001
|
||||
This allows to represent all possible combinations of capability
|
||||
names in the string. First generate the strings. */
|
||||
This allows the representation of all possible combinations of
|
||||
capability names in the string. First generate the strings. */
|
||||
result[1].str = result[0].str = cp = (char *) (result + *sz);
|
||||
#define add(idx) \
|
||||
cp = __mempcpy (__mempcpy (cp, temp[idx].str, temp[idx].len), "/", 1);
|
||||
|
|
|
|||
|
|
@ -21,10 +21,10 @@
|
|||
|
||||
/*
|
||||
* This is for COMPATIBILITY with Linux/x86 only. Linux/Alpha system
|
||||
* calls return an error indication in a3. This allows to return
|
||||
* arbitrary 64bit values in v0 (because negative values are not
|
||||
* mistaken as error numbers). However, C allows to return only one
|
||||
* value so the interface below folds the error indication passed in
|
||||
* calls return an error indication in a3. This allows arbitrary 64bit
|
||||
* values to be returned in v0 (because negative values are not
|
||||
* mistaken as error numbers). However, C allows only one value to
|
||||
* be returned, so the interface below folds the error indication passed in
|
||||
* a3 back into v0: it sets v0 to -errno if an error occurs. Thus,
|
||||
* no negative 64bit numbers can be returned. To avoid this problem,
|
||||
* use assembly stubs wherever possible/convenient.
|
||||
|
|
|
|||
Loading…
Reference in New Issue