delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/11/22/09:01:05

Date: Sun, 22 Nov 1998 14:46:56 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: david sharp <dsharp AT interport DOT net>
cc: djgpp AT delorie DOT com
Subject: Re: handling SIGFPE
In-Reply-To: <737lmv$14j$1@autumn.news.rcn.net>
Message-ID: <Pine.SUN.3.91.981122144636.17686Y-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com

On 22 Nov 1998, david sharp wrote:

> Say I want to handle floating point exceptions in a program
> (compiled with DJGPP). If the program has a handler for SIGFPE's 
> that directs the program to clear the directly affected
> variables, and then the program runs _control87() to clear
> FPU registers, and returns from the function where the
> offense occured, is that enough?

No.  Handlers for real CPU exceptions, like SIGFPE and SIGSEGV, cannot
return; if they do, the program will be aborted anyway.

This is because the way exceptions work on x86, when the handler
returns, the EIP is set to the same instruction that triggered the
exception in the first place, so you get the same exception again and
again.

So if your handler doesn't exit, it must longjmp, to avoid crashing
your program.

A better way to write a program that handles FP problems gracefully
is to disable all FP exceptions at the beginning, and then use a
custom-written `matherr' function to recover from FP problems (and
link with -lm, since the normal math functions in libc.a don't
support `matherr').

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019