I also find the wrong results to be unpleasant.
On shared hardware, you can rely on + , - , * , / and sqrt work and deliver a correctly rounded result. That is, they deliver a floating point number closest to the sum, difference, product, quotient or square root of their argument or arguments.
Some library functions, in particular log2 and log10 and exp2 and exp10 , traditionally have terrible implementations that were not even exactly rounded. True-rounded means that the function delivers one of two floating-point numbers, copying the exact result. Most modern pow implementations have similar problems. Many of these functions will even cause exact cases, such as log10(10000) and pow(7, 2) . Thus, comparisons of comparisons with these functions, even in the exact case, require trouble.
sin , cos , tan , atan , exp and log have robust rounded implementations on every platform I recently encountered. In the bad old days, on processors that use the x87 FPU to evaluate sin , cos and tan , you will get terribly wrong outputs for large inputs, and you will get input for larger inputs. CRlibm has correctly rounded implementations; they are not basic, because, as I was told, they have more unpleasant worst cases than traditional realistically rounded implementations.
Things like copysign and nextafter and isfinite work correctly. ceil and floor and rint , and friends always give an accurate result. fmod and friends too. frexp and friends work. fmin and fmax work.
Someone thought it would be a brilliant idea to make fma(x,y,z) compute x*y+z , compute x*y rounded to double , then add z and round the result to double . This behavior can be found on modern platforms. This is stupid, and I hate him.
I have no experience with hyperbolic trigger, gamma, or Bessel functions in my C library.
I should also mention that the popular compilers for the x86 32-bit game are different from another, broken set of rules. Since x87 is the only supported set of floating point instructions, and all x87 arithmetic is performed with an extended metric, calculations that will lead to overflows or overflows with double precision may not overflow or overflow. Also, since x87 also uses the extended value by default, you may not get the results you are looking for. Worse, compilers will sometimes pass intermediate results into variables of lesser precision, so you cannot even rely on your calculations when doing double in extended precision. (Java has a trick for doing 64-bit math with 80-bit registers, but it's quite expensive.)
I would recommend sticking with arithmetic on a long double if you are targeting 32-bit x86. Compilers should set FLT_EVAL_METHOD to the appropriate value, but I do not know if this was done universally.