On Wed, 19 Jan 2022 at 16:45, Jonathan Wakely <jwakely....@gmail.com> wrote: > > On Wed, 19 Jan 2022 at 15:46, Matthias Kretz <m.kr...@gsi.de> wrote: > > > > 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 > > No, because we get it from libc: > > #include_next <math.h>
So if you aren't seeing it after <cmath> is included, your libc is broken.
