Hacker News Reader

Comment by amszmidt | Hacker News Reader

I skimmed the standard and POSIX, but couldn’t find anything that an implementation is required to support FENV_ACCESS.

    4   Conformance

    A strictly conforming program shall use only those features of the language and
    library specified in this document.

    [...]

    The two forms of conforming implementation are hosted and freestanding. A
    conforming hosted implementation shall accept any strictly conforming program.

And it doesn't say anywhere in the standard that it's optional to support FENV_ACCESS pragma — it's a feature in the standard, so if you want to be a conforming implementation, you have to implement it. Of course, you can always be a non-conforming implementation, that also is allowed. Who's to stop you?

https://en.cppreference.com/cpp/preprocessor/impl:

“ISO C language standard requires that C compilers support the following three pragmas, and some C++ compiler vendors support them, to varying degrees, in their C++ frontends:

  #pragma STDC FENV_ACCESS arg      (1)
  #pragma STDC FP_CONTRACT arg      (2)
  #pragma STDC CX_LIMITED_RANGE arg (3)

where arg is either ON, OFF, or DEFAULT.”

⇒ it seems C compilers must support this (but C++ compilers need not)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678

At least some GCC devs claimed that the standard does not impose any requirements on these macros if a compiler does not claim strict ISO/IEC 6055 (aka IEE 754) conformance (which is still optional, and gcc and clang do not claim it).

Other devs disagree.

I admit "We don't have to comply with the standard if we don't claim to comply with the standard" is tautologically true.

But it does kind of support the whole "GCC C is not standard C" point.

A C implementation can be fully-compliant without conforming to ISO/IEC 6055, that's optional; question is just whether that optionality extends to fenv.h too. (at least how far I looked, imo it doesn't, and the pragma must exist, and valid fesetround calls (which there may be none of if no FE_* rounding modes are defined) must be represented by FLT_ROUNDS, even if it changes literally no actual float op behavior)

Reply on news.ycombinator.com