This is the mail archive of the
`libc-hacker@sourceware.cygnus.com`
mailing list for the glibc project.

Note that `libc-hacker` is a closed list. You may look at
the archives of this list, but subscription and posting are not open.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

*To*: GNU libc hacker <libc-hacker at sourceware dot cygnus dot com>*Subject*: ISO C99: Macros MATH_ERRNO, MATH_ERREXCEPT, math_errhandling*From*: Andreas Jaeger <aj at suse dot de>*Date*: 04 Jun 2000 14:20:52 +0200

ISO C99 seems to have added after the final draft some information about errno in <math.h> with the macros MATH_ERRNO, MATH_ERREXCEPT and math_errhandling. § 7.12.1 defines the usage of these three macros (§ 7.12 gives details about the declaration). The open question is which value math_errhandling should get. It can have the following values: - 0 meaning: Nothing known about errno and floating-point exceptions. - 1 (MATH_ERRNO): * errno is set to EDOM for a domain error; * errno is set to ERANGE for an overflow * errno might be set to ERANGE for underflows - 2 (MATH_ERREXCEPT): * An ``invalid'' floating-point exception is raised for a domain error; * ``divide-by-zero'' or ``overflow'' floating-point exceptions are raised for overflow * An ``underflow'' floating-point exception might be raised for underflow - 3 (MATH_ERRNO|MATH_ERREXCEPT): Combination of 1 and 2 I'm not sure if we're consistent in glibc's setting of errno and raising the flags. For example if -ffast-math is used, we cannot have math_errhandling & MATH_ERRNO set. Setting math_errhandling to MATH_ERREXCEPT should be fine but I'm not sure if we checked all places. If we'd like to be on the safe side, we could set math_errhandling to 0 - but that's lazyness, I do think we can do better ;-). What's the right value to use? I can provide a patch by the end of the week, I'm travelling on Monday/Tuesday. Andreas P.S. Here're some parts of the standard: [#9] The macros MATH_ERRNO MATH_ERREXCEPT expand to the integer constants 1 and 2, respectively; the macro math_errhandling expands to an expression that has type int and the value MATH_ERRNO, MATH_ERREXCEPT, or the bitwise OR of both. The value of math_errhandling is constant for the duration of the program. It is unspecified whether math_errhandling is a macro or an identifier with external linkage. If a macro definition is suppressed or a program defines an identifier with the name math_errhandling, the behavior is undefined. If the expression math_errhandling & MATH_ERREXCEPT can be nonzero, the implementation shall define the macros FE_DIVBYZERO, FE_INVALID, and FE_OVERFLOW in <fenv.h>. 7.12.1 Treatment of error conditions [#1] The behavior of each of the functions in <math.h> is specified for all representable values of its input arguments, except where stated otherwise. Each function shall execute as if it were a single operation without generating any externally visible exceptional conditions. [#2] For all functions, a domain error occurs if an input argument is outside the domain over which the mathematical function is defined. The description of each function lists any required domain errors; an implementation may define additional domain errors, provided that such errors are consistent with the mathematical definition of the function.194) On a domain error, the function returns an implementation-defined value; if the integer expression math_errhandling & MATH_ERRNO is nonzero, the integer expression errno acquires the value EDOM; if the integer expression math_errhandling & MATH_ERREXCEPT is nonzero, the ``invalid'' floating-point exception is raised. [#3] Similarly, a range error occurs if the mathematical result of the function cannot be represented in an object of the specified type, due to extreme magnitude. [#4] A floating result overflows if the magnitude of the mathematical result is finite but so large that the mathematical result cannot be represented without extraordinary roundoff error in an object of the specified type. If a floating result overflows and default rounding is in effect, or if the mathematical result is an exact infinity (for example log(0.0)), then the function returns the value of the macro HUGE_VAL, HUGE_VALF, or HUGE_VALL according to the return type, with the same sign as the correct value of the function; if the integer expression math_errhandling & MATH_ERRNO is nonzero, the integer expression errno acquires the value ERANGE; if the integer expression math_errhandling & MATH_ERREXCEPT is nonzero, the ``divide-by-zero'' floating-point exception is raised if the mathematical result is an exact infinity and the ``overflow'' floating-point exception is raised otherwise. [#5] The result underflows if the magnitude of the mathematical result is so small that the mathematical result cannot be represented, without extraordinary roundoff error, in an object of the specified type.195) If the result underflows, the function returns an implementation-defined value whose magnitude is no greater than the smallest normalized positive number in the specified type; if the integer expression math_errhandling & MATH_ERRNO is nonzero, whether errno acquires the value ERANGE is implementation- defined; if the integer expression math_errhandling & MATH_ERREXCEPT is nonzero, whether the ``underflow'' floating-point exception is raised is implementation- defined. -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |