Bug 44520 - What is the value of FE_ALL_EXCEPT?
Summary: What is the value of FE_ALL_EXCEPT?
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libc
Version: 7.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-06-13 23:28 UTC by Trevin Beattie
Modified: 2008-05-01 15:38 UTC (History)
0 users

Clone Of:
Last Closed: 2001-06-13 23:28:16 UTC

Attachments (Terms of Use)

Description Trevin Beattie 2001-06-13 23:28:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i586)

Description of problem:
I'm not really sure whether this is even a bug.  According to the C99
FE_UNDERFLOW, if defined, expand to integer contant expressions; and
FE_ALL_EXCEPT is the bitwise OR of all the preceding macros which are
defined by the implementation.  So I figure I can use a preprocessing
directive to quickly check whether any of the first five macros are defined
by simply comparing FE_ALL_EXCEPT to 0.  The result was surprising:
according to cpp, FE_ALL_EXCEPT == 0; but according to compiled code using
that macro, FE_ALL_EXCEPT == 0x3d.  How can the macro have two different

How reproducible:

Steps to Reproduce:
Compile and run the following code:

#include <stdio.h>
#define __USE_ISOC99 1
#include <fenv.h>

main ()
  puts ("Error: no exceptions are defined for this system.");
  return 1;
#elif FE_ALL_EXCEPT == 0
  printf ("Error: the list of exceptions defined for this system is empty
  return 1;
  printf ("The following exceptions are supported: #%x\n",
  return 0;

Actual Results:  Error: the list of exceptions defined for this system is
empty (0x3d).

Expected Results:  The following exceptions are supported: 0x3d

Additional info:

One could work around this inconsistency by using the following construct. 
It's a lot messier, but may actually work better if a system defines
FE_ALL_EXCEPT to be a non-zero value that does not include ANY of the
standard exceptions:

#if !defined (FE_DIVBYZERO) && !defined (FE_INEXACT) && !defined
(FE_INVALID) && !defined (FE_OVERFLOW) && !defined (FE_UNDERFLOW)

Comment 1 Jakub Jelinek 2001-07-23 15:22:59 UTC
This is pretty grey area in the standard, but according to Ulrich Drepper
glibc is fine.
The thing is what does for use in preprocessor macros mean.

Comment 2 Trevin Beattie 2001-07-23 17:59:54 UTC
I'm not sure what you're referring to with "for use in preprocessor macros", but
this whole report is a question of whether the FE_xxx macros should be suitable
for such use.  <bits/fenv.h> declares the FE_xxx macros in terms of enumeration
constants, which are allowed in integer constant expressions (draft standard
section 6.6), except when used in preprocessor macros (section 6.10.1).

In the introduction to the standard library functions, section 7.1.4 of the
draft C standard states "Each of the following statements applies unless
explicitly stated otherwise in the detailed descriptions that follow:" ... "All
object-like macros listed as expanding to integer constant expressions shall
additionally be suitable for use in #if preprocessing directives." (where
"object-like macro" is defined to mean a macro that doesn't take any arguments,
as opposed to a "function-like macro".)  As far as I can tell, that rule applies
to the FE_xxx macros defined in section 7.6.

Comment 3 Jakub Jelinek 2001-07-23 18:04:43 UTC
The thing is whether suitability for use in #if preprocessing directives
is satisfied if it is usable in defined() or if it must be used in other
#if expressions too.
I'd suggest you submit a clarify request for ISO C99 if you're looking
for a definitive answer.

Comment 4 Trevin Beattie 2001-08-13 18:06:46 UTC
To whom would I submit such a request?
I tried contacting ansionline@ansi.org two weeks ago, but they never responded.

Comment 5 Jakub Jelinek 2001-08-13 18:10:38 UTC
Ask Ulrich Drepper <drepper@redhat.com>. He knows whom to contact I believe.

Comment 6 Trevin Beattie 2001-08-16 00:18:56 UTC
I've started up a discussion on comp.std.c that had gotten rather involved, but
the final (though perhaps not official) word is this:

In article <3B7A5360.C0C19C67@wizard.net>,
"James Russell Kuyper Jr." <kuyper@wizard.net> writes:

"My personal opinion is that "suitable for use in #if preprocessing
directive" does NOT mean only that defined() can be applied to the macro
name. Such a requirement would be redundant with the specification that
they are macros. Assuming that it's not intended to be redundant (always
a tricky assumption when dealing with the standard), it seems to me that
the only plausible intent is that the macros should expand to their
actual numerical values in the context of a #if constant-expression.
However, that's not something the standard says explicitly. Perhaps it

Nick Maclaren was a lot more obscure, but in essence he wrote:
"I agree with you."

Note You need to log in before you can comment on or make changes to this bug.