Date: Mon, 18 May 1998 19:04:23 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Eric Rudd <rudd AT cyberoptics DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: Code to Fix sinh() in libm.a
In-Reply-To: <35604D33.B8353462@cyberoptics.com>
Message-ID: <Pine.SUN.3.91.980518185356.19060C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Mon, 18 May 1998, Eric Rudd wrote:

> I would appreciate receiving either the new libm code or the URL.

     ftp://is.elta.co.il/pub/libmnew.zip

> I have a question regarding the state of the coprocessor control
> register. I noticed that in DJGPP v2.01, overflows are masked. Since the
> IEEE floating-point formats are capable of representing infinity, this
> is appropriate. Thus, overflow to infinity is handled as gracefully as
> underflow to zero. The question I have is whether this state of the
> control word can be counted on in future versions of DJGPP, or if I must
> treat infinite results as errors.

I'm not sure I understand the question.  By ``overflows are masked'' do 
you mean that generation of FP exceptions due to overflow is masked?  If 
so, then it will continue to be that way; moreover, v2.02 will mask ALL 
exceptions, including the invalid operation.  IMHO, math functions should 
return Inf or a NaN as appropriate, and set errno and/or call matherr;
they should not crash the program.

But regardless, I think that any function that produces +/-Inf should set 
errno and call matherr.  More about this below.

> The ANSI C standard does not appear to
> resolve this question. For instance, in 7.5.4.1 (for the exp()
> function), it only says that "a range error occurs if the magnitude of x
> is too large." If infinities are allowed, then no argument will be "too
> large".

I'm no expert, but my interpretation is that Inf *is* too large and should
cause errno to be set to ERANGE.  I don't see any sense in silently
ignoring these cases: how else will the program know that something went
wrong after a certain run of FP computations? 

> Furthermore, in 7.5.4.4 (the log() function), it states that "a
> range error *may* occur if the argument is zero." (emphasis mine) I take
> this to mean that a range error is not *required* for infinite results.

IMHO, if we can return ERANGE in this case without sacrificing 
performance too much, then we should do it, even if it is not required.

> But none of this will work if I can't count on the state of the x87
> control register.

I think it is reasonable to make things work with the default setting of 
the control word, and document that if certain bits in it are changed, 
some features will not work.