diff options
author | Ulrich Drepper <drepper@redhat.com> | 2002-08-25 19:34:42 +0000 |
---|---|---|
committer | Ulrich Drepper <drepper@redhat.com> | 2002-08-25 19:34:42 +0000 |
commit | fd77c3615da7e73e590e2d85a86145a003f9ce6b (patch) | |
tree | ecca477e8addfc0433d5e807d1eb5e4352342286 /manual/lang.texi | |
parent | b65d9522d44268c81adcd750bcaa574210668edc (diff) | |
download | glibc-fd77c3615da7e73e590e2d85a86145a003f9ce6b.zip glibc-fd77c3615da7e73e590e2d85a86145a003f9ce6b.tar.gz glibc-fd77c3615da7e73e590e2d85a86145a003f9ce6b.tar.bz2 |
Update.
* elf/dl-load.c: Fix typo in comment. Add a few more __builtin_expect.
Diffstat (limited to 'manual/lang.texi')
-rw-r--r-- | manual/lang.texi | 40 |
1 files changed, 20 insertions, 20 deletions
diff --git a/manual/lang.texi b/manual/lang.texi index 9f5c540..96f6d9d 100644 --- a/manual/lang.texi +++ b/manual/lang.texi @@ -93,7 +93,7 @@ The @code{assert_perror} macro makes this easy. @deftypefn Macro void assert_perror (int @var{errnum}) Similar to @code{assert}, but verifies that @var{errnum} is zero. -If @code{NDEBUG} is defined, @code{assert_perror} tests the value of +If @code{NDEBUG} is not defined, @code{assert_perror} tests the value of @var{errnum}. If it is nonzero, @code{assert_perror} aborts the program after printing a message of the form: @@ -121,12 +121,12 @@ reporting invalid input or improper usage by the @emph{user} of the program. The information in the diagnostic messages printed by the @code{assert} -and @code{assert_perror} macro is intended to help you, the programmer, -track down the cause of a bug, but is not really useful for telling a user -of your program why his or her input was invalid or why a command could not -be carried out. What's more, your program should not abort when given -invalid input, as @code{assert} would do---it should exit with nonzero -status (@pxref{Exit Status}) after printing its error messages, or perhaps +and @code{assert_perror} macro is intended to help you, the programmer, +track down the cause of a bug, but is not really useful for telling a user +of your program why his or her input was invalid or why a command could not +be carried out. What's more, your program should not abort when given +invalid input, as @code{assert} would do---it should exit with nonzero +status (@pxref{Exit Status}) after printing its error messages, or perhaps read another command or move on to the next input file. @xref{Error Messages}, for information on printing error messages for @@ -253,8 +253,8 @@ func (const char *a, int b, @dots{}) @end smallexample @noindent -defines a function @code{func} which returns an @code{int} and takes two -required arguments, a @code{const char *} and an @code{int}. These are +defines a function @code{func} which returns an @code{int} and takes two +required arguments, a @code{const char *} and an @code{int}. These are followed by any number of anonymous arguments. @strong{Portability note:} For some C compilers, the last required @@ -299,9 +299,9 @@ values if you try to access too many arguments. You indicate that you are finished with the argument pointer variable by calling @code{va_end}. -(In practice, with most C compilers, calling @code{va_end} does nothing. -This is always true in the GNU C compiler. But you might as well call -@code{va_end} just in case your program is someday compiled with a peculiar +(In practice, with most C compilers, calling @code{va_end} does nothing. +This is always true in the GNU C compiler. But you might as well call +@code{va_end} just in case your program is someday compiled with a peculiar compiler.) @end enumerate @@ -338,8 +338,8 @@ regardless. There is no general way for a function to determine the number and type of the optional arguments it was called with. So whoever designs the -function typically designs a convention for the caller to specify the number -and type of arguments. It is up to you to define an appropriate calling +function typically designs a convention for the caller to specify the number +and type of arguments. It is up to you to define an appropriate calling convention for each variadic function, and write all calls accordingly. One kind of calling convention is to pass the number of optional @@ -463,7 +463,7 @@ Sometimes it is necessary to parse the list of parameters more than once or one wants to remember a certain position in the parameter list. To do this, one will have to make a copy of the current value of the argument. But @code{va_list} is an opaque type and one cannot necessarily -assign the value of one variable of type @code{va_list} to another variable +assign the value of one variable of type @code{va_list} to another variable of the same type. @comment stdarg.h @@ -479,7 +479,7 @@ the next update of the ISO C standard. @end deftypefn If you want to use @code{__va_copy} you should always be prepared for the -possibility that this macro will not be available. On architectures where a +possibility that this macro will not be available. On architectures where a simple assignment is invalid, hopefully @code{__va_copy} @emph{will} be available, so one should always write something like this: @@ -952,10 +952,10 @@ low-level aspects of the representation. @end itemize The mantissa of a floating point number represents an implicit fraction -whose denominator is the base raised to the power of the precision. Since -the largest representable mantissa is one less than this denominator, the -value of the fraction is always strictly less than @code{1}. The -mathematical value of a floating point number is then the product of this +whose denominator is the base raised to the power of the precision. Since +the largest representable mantissa is one less than this denominator, the +value of the fraction is always strictly less than @code{1}. The +mathematical value of a floating point number is then the product of this fraction, the sign, and the base raised to the exponent. @cindex normalized floating point number |