Use of C99 extra long double math functions after r236148

Steve Kargl sgk at
Mon May 28 22:54:07 UTC 2012

On Tue, May 29, 2012 at 08:04:36AM +1000, Peter Jeremy wrote:
> On 2012-May-28 13:31:59 -0700, Steve Kargl <sgk at> wrote:
> >On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
> >> One thing that could be done is to have a "math/cephes" port that adds 
> >> the extra C99 math functions.  This is already done in the math/sage 
> >> port, using a rather clever patch due to Peter Jeremy, that applies to 
> >> the cephes code.
> ...
> >This is a horrible, horrible, horrible idea.  Have you
> >looked at the cephes code, particularly the complex.h
> >functions?
> The cephes code is somewhat a mess layout-wise.  Algorithmetically,
> it seems somewhat variable - some functions are implemented (hopefully
> correctly) using semi-numerical techniques, whereas others just use
> mathematical identities which will result in precision loss - though
> most of the functions include accuracy information.
> I agree it would be far preferable to have a properly validated C99
> libm with all functions having maximum errors of a no more than a few
> LSB over their complete domain, as well as correct support for signed
> zeroes, infinities and signalling and non-signalling NaNs but that is
> a non-trivial undertaking.
> In the interim, how should FreeBSD handle apps that want a C99 libm?
> 1) Fail to build them
> 2) Provide possibly imperfect fallbacks for the unimplemented bits.
> If someone (I don't have the expertise) wants to identify the cephes
> functions that are sub-standard, we can include link-time warnings
> (as done for eg gets(3)) when they are used.

Given that cephes was written years before C99 was even
conceived, I suspect all functions are sub-standard.  For
example, AFAIK, none of the long double functions are
appropriate for any platform that has an 128-bit long double;
as cephes was written for an Intel 80-bit format.

If portmgr or a port maintainer wants to use a library with
untested implementations of missing libm functions, please do
not put it into /usr/local/lib and call it libm.


More information about the freebsd-current mailing list