Mail Archives: djgpp-workers/2000/03/16/11:22:28
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.
- Raw text -