www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/05/30/13:10:33

Date: Thu, 30 May 1996 19:59:52 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Thomas Demmer <demmer AT LSTM DOT Ruhr-UNI-Bochum DOT De>
Cc: djgpp AT delorie DOT com
Subject: Re: libm
In-Reply-To: <31AC658A.41C6@LSTM.Ruhr-UNI-Bochum.De>
Message-Id: <Pine.SUN.3.91.960530195226.15866E-100000@is>
Mime-Version: 1.0

On Wed, 29 May 1996, Thomas Demmer wrote:

> In order to check libm for bugs, I got somhow stuck in the
> jungle of signal(SIGFPE,my_handler) and matherr(). According
> to my (pretty old) C docs, matherr() is an  ANSI function, that
> can be redeclared in my own program.

No, it's not ANSI.  It isn't even POSIX, I think (or else DJ would have 
written one).

> With TC2.0 this
> works quite OK, djgpp and AIX cc do not handle that.

There is `matherr' in libm.a, so I'd guess if you link with -lm you 
should be able to use it.  But this will probably only work if you set up 
x87 to not generate exceptions, and provided that the code of libm.a 
functions tests the x87 status word and calls `matherr' when it sees any 
abnormal bits set.  (I don't have time right now to look into libm 
sources and see whether it is done this way.)

The default math functions in libc.a don't support `matherr'.

> So, how can I find out from the signal handler which
> function caused the the signal with which args?

AFAIK, this is not how `matherr' is designed to work, see above.  It shold
be called from the function that caused the problem, not from the signal
handler. 

- Raw text -


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