Bug 44520

Summary: What is the value of FE_ALL_EXCEPT?
Product: [Retired] Red Hat Linux Reporter: Trevin Beattie <trevin>
Component: libcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-06-13 23:28:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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
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)
  ...

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 two weeks ago, but they never responded.


Comment 5 Jakub Jelinek 2001-08-13 18:10:38 UTC
Ask Ulrich Drepper <drepper>. 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>,
"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."