On Wednesday, 19 January 2022 16:21:15 CET Jonathan Wakely wrote: > On Wed, 19 Jan 2022, 12:45 Matthias Kretz, <m.kr...@gsi.de> wrote: > > On Wednesday, 19 January 2022 13:07:26 CET Jonathan Wakely wrote: > > > So is it a macro or not? > > > > I agree the quote I used is unclear. The complete paragraph: > > > > The macros > > > > MATH_ERRNO > > MATH_ERREXCEPT > > > > expand to the integer constants 1 and 2, respectively; the macro > > > > math_errhandling > > > > expands to an expression that has type int and the value MATH_ERRNO, > > MATH_ERREXCEPT, or the bitwise OR of both. The value of math_errhandling > > is > > constant for the duration of the program. It is unspecified whether > > math_errhandling is a macro or an identifier with external linkage. If a > > macro > > definition is suppressed or a program defines an identifier with the name > > math_errhandling, the behavior is undefined. If the expression > > math_errhandling & MATH_ERREXCEPT can be nonzero, the implementation shall > > define the macros FE_DIVBYZERO, FE_INVALID, and FE_OVERFLOW in > > <fenv.h>. > > But that still says "the macro math_errhandling" and then says it might not > be a macro.
There's also [cmath.syn] https://eel.is/c++draft/cmath.syn which says: #define math_errhandling see below So, FWIW, libstdc++ is required to define math_errhandling as a macro in <cmath>. Thus, the original error (that math_errhandling wasn't defined even after <cmath> was included) really needs a fix in <cmath>. :-P -- ────────────────────────────────────────────────────────────────────────── Dr. Matthias Kretz https://mattkretz.github.io GSI Helmholtz Centre for Heavy Ion Research https://gsi.de stdₓ::simd ──────────────────────────────────────────────────────────────────────────
