Re: cmath vs. math.h vs isfinite

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 25 Aug 2026 12:08:25 +0200
    From:        Thomas Klausner <wiz%netbsd.org@localhost>
    Message-ID:  <ao1orwdcLu0rC4nY%exadelic.gatalith.at@localhost>

  | Is there some standard lawyering that makes NetBSD ok, or is this
  | something that should be fixed in our headers?

I suspect probably the latter.

It happens because in <math.h> the only definition of isfinite() is:

#define isfinite(__x)   __fpmacro_unary_floating(isfinite, __x)

and in <cmath> it does:

#undef isfinite

so if both are included, there is no definition for the C isfinite()
remaining -- <cmath> includes <math.h> so it makes no difference which
order the two are included in, if you include <cmath> first, then
<math.h> comes from it, <cmath> later undefines isfinite() and there
is nothing to put it back, the double-include-protection means a later
include of <math.h> does nothing, if you include <math.h> first,
then that one wins, the include of it from <cmath> does nothing, but the
later #undef still works.

Why I think <math.h> needs fixing, is that while it is perfectly OK
to define almost any standard function as a macro, a version of it
declared as an actual function is needed as well, and we don't have
that.  That allows for this #undef stuff to work, when the application
(or just the C++ system) wants the real function.  It also allows for
application code to do stuff like

	bool finite = (isfinite)(f);

So, we need a standard C declaration for isfinite() in math.h, before
the macro definition of it, and an actual implementation of it in libc

Or that is how it appears to me anyway.

kre