X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Thu, 16 Mar 2000 18:19:27 +0100 (MET) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: Eli Zaretskii cc: djgpp-workers AT delorie DOT com Subject: Re: Unnormals??? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: dj-admin AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Thu, 16 Mar 2000, Eli Zaretskii wrote: > On Thu, 16 Mar 2000, Hans-Bernhard Broeker wrote: > > > I'm not sure it's a good idea to enable FP exceptions. They make ANSI > > > compliance in math functions next to impossible, since AFAIK the standard > > > explicitly forbids math functions to crash the program. > > > > Not so for 'signaling NaNs', I think. Quoting the C99 draft, > > section 5.2.4.2.2, paragraph 3: [...] > This is not the part of the standard I was worried about. C89 explicitly > required math functions not to crash, but to set errno instead. What > does C99 say about that? 7.12.1 Treatment of error conditions [#1] The behavior of each of the functions in is specified for all representable values of its input arguments, except where stated otherwise. This leaves us with the question wether a NaN (signaling or not) is 'representable value'. Compared to C89, this has been weakened a bit. There used to be second sentence: Each function shall execute as if it were a single operation, without generating any externally visible exceptions. This is no longer there, and there doesn't seem to be a comment in the Rationale giving a possible reason for that decision. But there is this paragraph: The Standard has been crafted to neither require nor preclude any popular floating-point implementation. This principle affects the definition of domain error: an implementation may define extra domain errors to deal with floating-point arguments such as infinity or "not-a-number" (NaN). To me, this means we're free to do whatever we want if the user passes NaN or Infinity, to any given function that is not documented to behave in a defined way, by the standard. [...] > I'm not sure what that means. "sqrt(-1)" produces the invalid operation > exception. Ooops, my fault, I forgot to read on to the next page, where other sources of invalid operation SIGFPE were listed... Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.