Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 May 2013 16:01:01 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Steve Kargl <sgk@troutmask.apl.washington.edu>
Cc:        "freebsd-numerics@freebsd.org" <freebsd-numerics@freebsd.org>, David Chisnall <theraven@freebsd.org>
Subject:   Re: C99 Long Double Math Functions
Message-ID:  <20130521151407.L1076@besplex.bde.org>
In-Reply-To: <20130519170901.GA96649@troutmask.apl.washington.edu>
References:  <D78B342A-4316-4EBF-B869-DF50EA353D99@FreeBSD.org> <20130519170901.GA96649@troutmask.apl.washington.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 19 May 2013, Steve Kargl wrote:

> On Sun, May 19, 2013 at 12:10:28PM -0400, David Chisnall wrote:
>> Hi Everyone,
>>
>> In February, lots of people had code  ready to commit for the C99 long double math.h functions.  This code is still not in and is an increasingly serious problem for a lot of software.  Two weeks from today, I will commit a patch that just calls the double versions of these for all of the long double functions.  If you have a better implementation of any of them, please commit it before then.  Style nits can be worked out later.  Small bugs in corner cases can also be fixed later: it is far worse for us to have no implementation of these than to have a slightly buggy one, because it just drives people to use platforms that have very buggy versions of them instead of FreeBSD.
>>
>> David

Please use the unix newline in mail.

History shows that style nits rarely get worked out later, and usually
increase.

> Unfortunately, life gets in the way of hacking on FreeBSD.  However,
> it so happens that I'll be sending a patch to das@ in early June
> with an expl() update and an implementation for expm1l().

Unfortunately, das@ has been inactive since he got his PhD.

I spent a half of yesterday so retesting libm for correctness and
cleaning up log*.  Style problems in log* currently include its
layering.  I am now trying hacks like multiple includes of __FILE__
to avoid pessimizations and complications from using inline functions.
These give worse layering and different complications.  If you promise
to fix the style "nits" in this (move 100K of code around to perfect
places), then it is committable as it is.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130521151407.L1076>