1

Consider this code:

/* t0.c */
#pragma STDC FENV_ACCESS ON
#include "t0.h"

Then in t0.h how to check the state of STDC FENV_ACCESS?

/* t0.h */
/* how to check the state of STDC FENV_ACCESS? */
/* something like: #if STDC FENV_ACCESS == ON */

If not possible, then:

  1. Why not possible?
  2. Will it be useful to add this feature to the C standard?
pmor
  • 5,392
  • 4
  • 17
  • 36

2 Answers2

3

(1) Why not possible?

It is possible with a custom cpp as rryker's answer mentioned. Otherwise, I would have said "no" because the compiler uses the pragmas and that comes after the cpp pass/stage.

(2) Will it be useful to add this feature to the C standard?

No, probably not. For the above mentioned reason.

And, because, drawing a leaf from what is already common (e.g. autoconf), we can reverse the problem to get the desired results without changing existing compilers.

Define (e.g.) a features.h:

#ifdef STDC_FENV_ACCESS_ON
#if STDC_FENV_ACCESS_ON
#pragma STDC FENV_ACCESS ON
#else
#pragma STDC FENV_ACCESS OFF
#endif
#endif

UPDATE:

Re: "custom cpp as rryker's answer mentioned": hm, where is the rryker's answer? I don't see it. – pmor

I wrote that before rryker deleted his answer [partly] because of critique/comments from HolyBlackCat that couldn't be addressed immediately. My inference was rryker would be able to improve his answer and undelete it, so I left up the reference.

The link rryker based his answer on was specific extensions provided by clang: https://clang.llvm.org/docs/LanguageExtensions.html The features that rryker's answer referred to were: the __has_feature and __has_extension macros [since version 10].

That's the reference. However, with a bit of conjecture on my part, I'll try to summarize.

IIRC, clang's cpp is not a separate program that is only loosely connected to the compiler [e.g. like it is with gcc].

With clang, the preprocessor is a [more] tightly integrated stage within the compiler itself. My presumption is that this was [initially] done for speed and code reuse.

But, as a "side effect" of that:

  1. clang's cpp can have much more intimate knowledge of the compiler's inner workings.

  2. And, if it's more efficient/desirable, clang's cpp stage could also do more of the early (e.g.) pragma processing.

  3. And, cpp could have access to (e.g.) all the -f* arguments/options the compiler sees.

  4. So, it has all of the tools that make #if/#ifdef on the above __has_* macros feasible.

Craig Estey
  • 30,627
  • 4
  • 24
  • 48
  • Re: "custom cpp as rryker's answer mentioned": hm, where is the rryker's answer? I don't see it. – pmor Jan 10 '22 at 20:28
  • 1
    @pmor He deleted his clang-specific answer, referring to mine as more general :-) – Jens Jan 10 '22 at 20:53
3

In addition to the other answers, and if t0.c is actually under your control, you may define appropriate macros whenever a #pragma is used.

/* t0.c */
#pragma STDC FENV_ACCESS ON
#define PRAG_FENV_ACCESS_ON
#include "t0.h"

This works independently of toolchain vendor. It's a variation of the same theme used to check the presence of typedefs in the preprocessor.

Jens
  • 69,818
  • 15
  • 125
  • 179
  • Re: "variation of the same theme": where can I read more on this? – pmor Jan 10 '22 at 20:30
  • 1
    @pmor Likely in your system headers. E.g. on FreeBSD, there are macros such as `_RSIZE_T_DEFINED`, next to the `typedef mumble rsize_t`. – Jens Jan 10 '22 at 20:50
  • FYI: reminds me somehow of [this](https://stackoverflow.com/questions/67599973/is-there-a-standard-way-to-check-at-compile-time-that-file-is-being-preprocessed), which maybe somehow related / useful. – pmor Jan 10 '22 at 21:04