Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!oliveb!sun!dgh!dgh
From: dgh@dgh.UUCP
Newsgroups: comp.lang.c
Subject: Re: Help in dealing with floating point exceptions in C on  UNIX/VAX
Message-ID: <13514@sun.uucp>
Date: Tue, 17-Feb-87 22:38:24 EST
Article-I.D.: sun.13514
Posted: Tue Feb 17 22:38:24 1987
Date-Received: Thu, 19-Feb-87 06:43:22 EST
References: <4433@brl-adm.ARPA>
Sender: news@sun.uucp
Lines: 38
Summary: matherr not much help

>The problem I'm having is that
>I can't figure out how to trap floating point exceptions.

The consensus response, at least from System V users, is to use matherr(3M).
The original poster hasn't said whether that was any help, and it's 
instructive to realize why it may not be.  Matherr is only counted on
for dealing with exceptions that arise in certain libm subroutines.
On most System V implementations matherr is no help for the much more 
common cases of floating-point exceptions,
such as overflow and division by zero, that arise in atomic operations
such as +-*/.  These operations are usually implemented in hardware nowadays, 
except on PC's.

Users of 68020/68881 systems have a complementary problem:  they would
sacrifice considerable performance to implement matherr's requirements
because the 68881 performs many libm subroutines in a single instruction.

Correctly implemented IEEE arithmetic offers a uniform solution since 
all atomic operations must signal exceptions if they encounter them,
and it is usually not too difficult to make library functions look like
atomic operations if they are not so provided in the hardware.  VAX
reserved operands can be exploited to provide some of the exception-handling
capabilities of IEEE arithmetic; I have heard that 4.4 BSD may actually
have some software support for that.  And IEEE and VAX arithmetic are the
only floating-point architectures of consequence in the workstation market,
at least.  

Since the original poster referred to C code, 4.3 BSD, and a VAX, 
it seems likely that the solution to her problem can be developed by consulting
sigvec(2), signal(3),
or /usr/include/signal.h, to see how to declare a signal handler for SIGFPE 
and enable it at the start of main().


David Hough

ARPA: dhough@sun.com
UUCP: {ucbvax,decvax,allegra,decwrl,cbosgd,ihnp4,seismo}!sun!dhough