__FLOAT_BITS and __DOUBLE_BITS macros used union compound literals,
now they are changed into static inline functions. A good C compiler
generates the same code for both and the later is C++ conformant.
some programs (procps, babl) expect it, and it doesn't seem to
cause any harm to just add it.
it's small and straightforward.
since math.h also defines MAXFLOAT, we undef it in both places,
before defining it.
j0l,j1l,jnl,y0l,j1l,jnl are gnu extensions, bsd and posix do not
have them.
noone seems to use them and there is no plan to implement them any
time soon so we shouldn't declare them in math.h.
previously, everything was going through an intermediate conversion to
long double, which caused the extern __fpclassifyl function to get
invoked, preventing virtually all optimizations of these operations.
with the new code, tests on constant float or double arguments compile
to a constant 0 or 1, and tests on non-constant expressions are
efficient. I may later add support for __builtin versions on compilers
that support them.
the old behavior of exposing nothing except plain ISO C can be
obtained by defining __STRICT_ANSI__ or using a compiler option (such
as -std=c99) that predefines it. the new default featureset is POSIX
with XSI plus _BSD_SOURCE. any explicit feature test macros will
inhibit the default.
installation docs have also been updated to reflect this change.
while musl itself requires a c99 compiler, some applications insist on
being compiled with c89 compilers, and use of "inline" in the headers
was breaking them. much of this had been avoided already by just
skipping the inline keyword in pre-c99 compilers or modes, but this
new unified solution is cleaner and may/should result in better code
generation in the default gcc configuration.
this function never existed historically; since the float/double
functions it's based on are nonstandard and deprecated, there's really
no justification for its existence except that glibc has it. it can be
added back if there's ever really a need...
two issues: (1) the type was wrong (unsigned instead of signed int),
and (2) the value of FP_ILOGBNAN should be INT_MIN rather than INT_MAX
to match the ABI. this is also much more useful since INT_MAX
corresponds to a valid input (infinity). the standard would allow us
to set FP_ILOGB0 to -INT_MAX instead of INT_MIN, which would give us
distinct values for ilogb(0) and ilogb(NAN), but the benefit seems way
too small to justify ignoring the ABI.
note that the macro is just a "portable" (to any twos complement
system where signed and unsigned int have the same width) way to write
INT_MIN without needing limits.h. it's valid to use this method since
these macros are not required to work in #if directives.
this is a nonstandard function so it's not clear what conditions it
should satisfy. my intent is that it be fast and exact for positive
integral exponents when the result fits in the destination type, and
fast and correctly rounded for small negative integral exponents.
otherwise we aim for at most 1ulp error; it seems to differ from pow
by at most 1ulp and it's often 2-5 times faster than pow.
thanks to the hard work of Szabolcs Nagy (nsz), identifying the best
(from correctness and license standpoint) implementations from freebsd
and openbsd and cleaning them up! musl should now fully support c99
float and long double math functions, and has near-complete complex
math support. tgmath should also work (fully on gcc-compatible
compilers, and mostly on any c99 compiler).
based largely on commit 0376d44a890fea261506f1fc63833e7a686dca19 from
nsz's libm git repo, with some additions (dummy versions of a few
missing long double complex functions, etc.) by me.
various cleanups still need to be made, including re-adding (if
they're correct) some asm functions that were dropped.
the previous version not only failed to work in c++, but also failed
to produce constant expressions, making the macros useless as
initializers for objects of static storage duration.
gcc 3.3 and later have builtins for these, which sadly seem to be the
most "portable" solution. the alternative definitions produce
exceptions (for NAN) and compiler warnings (for INFINITY) on newer
versions of gcc.
Szabolcs Nagy
rofl0r
Rich Felker