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 values? How reproducible: Always Steps to Reproduce: Compile and run the following code: #include <stdio.h> #define __USE_ISOC99 1 #include <fenv.h> int main () { #ifndef FE_ALL_EXCEPT 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 (%#x).\n", FE_ALL_EXCEPT); return 1; #else printf ("The following exceptions are supported: #%x\n", FE_ALL_EXCEPT); return 0; #endif } 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) ...
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 ansionline two weeks ago, but they never responded.
Ask Ulrich Drepper <drepper>. 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>, "James Russell Kuyper Jr." <kuyper> 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 should?" Nick Maclaren was a lot more obscure, but in essence he wrote: "I agree with you."