Re: e_pow.c bug

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Mon, 2004-04-12 at 18:39, Steve Moshier wrote:
> On Mon, 12 Apr 2004, Bryce McKinlay wrote:
> 
> > Interesting. It looks like our StrictMath.java, which is a port of the C
> > code, also suffers from this problem. As does Sun's JRE as of 1.5-beta,
> > from looking at the following test case. Any idea if this issue has been
> > reported to Sun?
> 
> To my knowledge, Sun Microsystems has never lifted a finger to maintain
> or support fdlibm.  They specifically refused to address other fdlibm
> bugs that I showed them years ago, when the package was first released.
> But since you brought it up, I will write to one of the people who were
> involved with the development.

I looked into this last week for GNU Classpath and the spec actually
says we need to have the exact same bugs as one specific fdlibm
release... Hmmm mail.gnu.org is down, so let me quote:
        
        See the spec for java.lang.Math and java.lang.StrictMath:
        "The Java math library is defined with respect to the version of
        fdlibm dated January 4, 1995. Where fdlibm provides more than
        one definition for a function (such as acos), use the "IEEE 754
        core function" version (residing in a file whose name begins
        with the letter e)."
        
        For us the "upstream" for these functions is actually libgcj
        since they test against a lot more platforms then we do at the
        moment. But they haven't actually been applying patches to it
        for years. Which isn't surprising seen the fact that the spec is
        so specific about a particular version of fdlibm.
        
        As far as I could see there isn't a real distribution (package)
        of fdlibm except for the raw sources at
        http://www.netlib.org/fdlibm/ which is the reason we ship it
        together with GNU Classpath.

Should be follow their buggy spec?

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part