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: > > On Wed, 19 Jan 2022 at 08:10, Matthias Kretz wrote: > > > Follow-up to my last patch. This one is a more thorough fix. Tested on > > > x86_64- > > > linux. OK for trunk? > > > > > > ---- 8< ---- > > > > > > Use SFINAE magic to support: "It is unspecified whether > math_errhandling > > > is a macro or an identifier with external linkage." [C Standard] > > > > The patch is OK for trunk, but I don't understand what the C standard > means > > here. > > > > "the macro math_errhandling expands to [...]. It is unspecified whether > > math_errhandling is a macro or an identifier with external linkage." > > > > 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. I'll ask some WG14 people for clarity, but it doesn't affect your patch.
