+(other long double representations may be supported in the future, until then
+long double math functions will be missing on non-supported platforms)
+<li>On soft-float architectures fenv should not be expected to work according to
+the c and ieee standards (ie. rounding modes and exceptions are not supported,
+the fenv functions are dummy ones)
+<li>Floating-point exception flags should be properly set in math functions
+according to c99 annex F, but without using fenv.h
+(eg. overflow flag can be raised by 0x1p900*0x1p900, because this works even
+without fenv support)
+<li>Most functions need to be precise only in nearest rounding mode.
+<li>Returned floating-point values should be correctly rounded in most cases,
+but the last bit may be wrong:
+<pre>
+ |error| < 1.5 ulp
+</pre>
+should hold.
+(error is the difference between the exact result and the calculated
+floating-point value)
+(in theory correct rounding can be achieved but with big implementation cost,
+see <a href="http://lipforge.ens-lyon.fr/www/crlibm/">crlibm</a>)
+<li>At least the following functions must be correctly rounded:
+ceil, copysign, fabs, fdim, floor, fma, fmax, fmin, frexp, ldexp,
+modf, nearbyint, nextafter, nexttoward, rint, round, scalbln, scalbn,
+sqrt, trunc.
+<li>Mathematical properties of functions should be as expected
+(monotonicity, range, symmetries).
+<li>If the FPU precision is altered then nothing is guaranteed to work.
+(ie. when long double does not have full 80bit precision on i386 then things may break)
+<li>Signaling NaN is not supported
+<li>Quiet NaN is supported but all NaNs are treated equally without special
+attention to the internal representation of a NaN
+(eg. the sign of NaN may not be preserved).
+<li>Most gcc bug workarounds should be removed from the code
+(STRICT_ASSIGN macro is used when excessive precision is harmful and
+FORCE_EVAL when expressions must be evaluated for their sideeffect, other
+usage of volatile is not justified, hacks around long double constants are
+not justified eventhough gcc can miscompile those with non-default FPU setting)
+<li>Whenever fenv is accessed the FENV_ACCESS pragma of c99 should be used
+(eventhough gcc does not yet support it), and all usage of optional FE_
+macros should be protected by #ifdef
+<li>For bit manipulation of floating-point values an union should be used
+(eg. union {float f; uint32_t i;})
+<li>uint32_t and uint64_t should be used for bit manipulations.
+(eg signed int must not be used in bit shifts etc when it might invoke
+undefined or implementation defined behaviour).
+<li>POSIX namespace rules must be respected.
+<li>c99 hexfloat syntax (0x1.0p0) should be used when it makes the
+code clearer, but not in public header files
+(those should be c++ and ansi c compatible)
+<li>The 'f' suffix should be used for single precision values (0.1f) when the
+value cannot be exactly represented ((float)0.1 is not ok, that style may lead
+to double rounding issues, but eg. 1.0 or 0.5 can be used instead of 1.0f or
+0.5f)
+<li>Prefer classification macros (eg. isnan) over inplace bit hacks.
+<li>For every math function there should be a c implementation.
+(a notable exception now is sqrtl, since most fpu has instruction for it
+and on soft-float architectures long double == double)
+<li>The c implementation of a long double function should use ifdefs with the
+LDBL_MANT_DIG etc constants from float.h for architecture specific
+implementations.
+<li>In the musl source tree math.h functions go to src/math, complex.h functions
+to src/complex and fenv.h functions to src/fenv. And files are named after the
+functions they implement.