Red Hat Bugzilla – Bug 44520
What is the value of FE_ALL_EXCEPT?
Last modified: 2008-05-01 11:38:00 EDT
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
standard, the macros FE_DIVBYZERO, FE_INEXACT, FE_INVALID, FE_OVERFLOW, and
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
Steps to Reproduce:
Compile and run the following code:
#define __USE_ISOC99 1
puts ("Error: no exceptions are defined for this system.");
#elif FE_ALL_EXCEPT == 0
printf ("Error: the list of exceptions defined for this system is empty
printf ("The following exceptions are supported: #%x\n",
Actual Results: Error: the list of exceptions defined for this system is
Expected Results: The following exceptions are supported: 0x3d
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
#if !defined (FE_DIVBYZERO) && !defined (FE_INEXACT) && !defined
(FE_INVALID) && !defined (FE_OVERFLOW) && !defined (FE_UNDERFLOW)
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.
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.
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.
To whom would I submit such a request?
I tried contacting firstname.lastname@example.org two weeks ago, but they never responded.
Ask Ulrich Drepper <email@example.com>. He knows whom to contact I believe.
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." <firstname.lastname@example.org> 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."