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
──────────────────────────────────────────────────────────────────────────

Reply via email to