OpenLibm has an implementation of fenv.h internally. This may be
problematic in case you want it to build against the host system's
implementation, as it would require you to somehow take the fenv.h file
out of the compiler search path.
Simply use a different naming scheme, similar to openlibm.h and
openlibm_complex.h. If we want to build against the host's fenv.h, we
can simply add an '#include <fenv.h>' from within this header.
I am currently working on building openlibm against stock copies of
<math.h>, instead of the openlibm.h header. It seems that a C compliant
<math.h> header can be used as a drop-in replacement for openlibm.h,
with the exception that it lacks cpack*().
In FreeBSD SVN r275819 I patched up the math library by replacing
cpack*() by CMPLX*(). That way many functions become less tied to the
intrinsics of the math library. Make the same change to openlibm.
We already provide lgammaf_r() and lgamma_r(). It's not hard to also add
lgammal_r(), for consistency.
I am currently working on porting openlibm to an environment where
global state, and thus signgam, is not available. By adding lgammal_r(),
I can trivially disable support for signgam by just patching up
src/e_lgamma{f,,l}.c. That way there is no need to patch up the actual
algorithms.
When building openlibm with Clang, I seem to get a lot of warnings in
ld80/ related to some prototypes for long double functions that are
missing. This seems to be because we don't define _DECLARE_C99_LDBL_MATH
anywhere.
It seems that this definition only existed on FreeBSD, as certain C99
math functions were not present yet. The prototypes were simply there as
placeholders. This flag has been removed upstream (FreeBSD SVN r236148).
Letting tgammal() modify signgam has two disadvantages:
- It breaks valid code that assumes that the value of signgam is not
clobbered by calls to tgammal().
- It makes this function depend on the presence of signgam. signgam is
an X/Open System Interface. It is not part of the C standard.
Instead of using all sorts of operating system specific constructs, we
can just query the compiler which byte order is being used. This has the
advantage that the code builds on new platforms without any tweaks.
<sys/cdefs.h> is not a standard header. Instead, we'd better pull in a
common header like <stdio.h>. It is very likely that such a header
already provides the necessary bits.
It seems that this header conditionally tests whether <complex.h> is
included, as the 'complex' keyword is otherwise not available. This
version of math_private.h includes <complex.h> unconditionally, so there
is no need to test against this.
The finite() function has been superseded by isfinite(). There is also
no need to use scalb(), as the exponent is also an integer value. We can
simply use scalbn().
There is also no need to use __isnanf(). The values passed are
guaranteed to be of type float, meaning we can safely use the standard
isnan().
This test is also present in FreeBSD's <machine/ieeefp.h>. For FreeBSD
it makes sense, but for a portable math library, we cannot assume that
the system has a header file like <sys/cdefs.h> and that it uses a
common header guard.
