Re: Use of C99 extra long double math functions after r236148

On 28 May 2012, at 05:35, Rainer Hurling wrote:

> Yesterday r236148 (Allow inclusion of libc++ <cmath> to work after including math.h) was comitted to head, many thanks.
> 
> Does this mean, that extra long double functions like acoshl, expm1l or log1pl are now "really implemented"? As far as I understand, they had only been declared before?

They are still not implemented.  The <cmath> header in libc++ provides wrappers around these functions for C++, but if they are not declared then the compiler throws an error.  Now there is a linker error if they are used, but if they are not used then it works irrespective of whether you just include <cmath> or do undefined things like include <math.h> first.

> If this is right, are they usable on a recent CURRENT, built with gcc42 (system compiler), by ports which use gcc46 (not clang)? If not, are there any plans to implement these functions in the near future?

I think they're one of the last bits of C99 / C11 that anyone actually cares about (C11 unicode support being another), so they'll probably get done at some point, but doing them correctly is nontrivial, except on platforms where double and long double are the same.  

> The use of C99 extra long double functions would be of interest for example for programs like math/R, especially its upcoming releases.

I would be very wary of anything that depends on long double.  The C spec makes no constraints on the range of float, double, or long double, but by convention on most platforms float is an IEEE 754 32-bit floating point value and double is 64-bit.  No such conventions apply to long doubles and I know of (widely deployed) platforms where they are 64 bits, 80 bits and 128 bits, respectively.  I believe on PowerPC FreeBSD actually gets it wrong and uses 64 bits even though the platform ABI spec recommends using 128 bits.  x86 uses 80-bit x87 values (although sizeof(long double) may be 16 because they have some padding bytes in memory).  If your program is tolerant of a potential variation in precision between 64 bits and 128 bits, then it is probably tolerant of just using doubles.

David