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]

ISO C99: Macros MATH_ERRNO, MATH_ERREXCEPT, math_errhandling



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]