X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Thu, 16 Mar 2000 16:36:36 +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: [...] > > So the current behaviour would also be allowed by the standard. Just let > > such programs get what they asked for: a crash of the program by SIGFPE. > > 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: quiet NaN propagates through almost every arithmetic operation without raising an exception; a signaling NaN generally raises an exception when occurring as an arithmetic operand.16) and the footnote: 16)IEC 60559:1989 specifies quiet and signaling NaNs. For implementations that do not support IEC 60559:1989, the terms quiet NaN and signaling NaN are intended to apply to encodings with similar behavior. > I think our move > to mask all FP exceptions in v2.02 and later was in the right direction. Invalid operation may be the single one that can be left unmasked, and IMHO should. There's no way to trigger it in a C program that hasn't enacted undefined behaviour before, AFAICS, so we should be on the safe side. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.