News for hackers. Stuff that matters.
Re:your C is not standard C by dzaima on Wednesday October 14, 2026 @09:50PM (#50098144)
> gcc, however, always defines FLT_ROUNDS to 1

Well, considering that gcc doesn't support the FENV_ACCESS pragma, and as such all fesetround calls are always UB, it is valid for it to act as if the rounding mode never changes from the default :)

Re:your C is not standard C by uecker on Thursday October 15, 2026 @01:20AM (#50099495)
Well, it is not ok to not support FENV_ACCESS though.
Re:your C is not standard C by amszmidt on Thursday October 15, 2026 @02:32AM (#50100004)
I skimmed the standard and POSIX, but couldn’t find anything that an implementation is required to support FENV_ACCESS.
Re:your C is not standard C by Someone on Thursday October 15, 2026 @03:43AM (#50100543)
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)

Re:your C is not standard C by gpderetta on Thursday October 15, 2026 @05:40AM (#50101338)
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.

Re:your C is not standard C by Bratmon on Thursday October 15, 2026 @05:51PM (#50110879)
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.

Re:your C is not standard C by dzaima on Thursday October 15, 2026 @08:48PM (#50112297)
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)
Re:your C is not standard C by Joker_vD on Thursday October 15, 2026 @04:51AM (#50101018)

    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?
Re:your C is not standard C by dzaima on Thursday October 15, 2026 @05:38AM (#50101325)
Yeah, that's still an issue of course. Root cause is still just that gcc utterly doesn't support any of fenv anything.

That said, I was surprised that it's mandatory by the standard (and wasn't made optional later like VLAs); feels rather unlike C to require such precise control over something it doesn't even specify any behavior of - imagine if we had mandatory macros for integer overflow behavior and whatnot!

...That "that said" said, C11 does also contain:

> Each of the macros FE_DOWNWARD FE_TONEAREST FE_TOWARDZERO FE_UPWARD is defined if and only if the implementation supports getting and setting the represented rounding direction by means of the fegetround and fesetround functions.

so presumably one could just not define those and get away with not implementing (at least the rounding mode part of) fenv.h, properly allowing the `#define FLT_ROUNDS 1` hack? gcc+glibc does define those, though.