Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!cetia.UUCP!rob
From: rob@cetia.UUCP
Newsgroups: comp.windows.x
Subject: SIGFPE in miFillSppPoly()
Message-ID: <8906211551.AA07986@inria.inria.fr>
Date: 21 Jun 89 15:51:32 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 34

Occasionally we get Not-a-Number floating point exceptions in ceil()
called from miFillSppPoly().

The system we are running under is derived from Motorola system V.2
but with NFS, sockets, and other BSD goodies.

i checked out how ceil() performs on a sun and on another BSD system
and it returns something sensible when passed a NaN as parameter
(MAXINT or -MAXINT depending on whether what wasn't a number was positive
or negative).

However, with the motorola maths libraries ceil(), in this situation,
generates a SIGFPE.

i have looked at the code, briefly, for miFillSppPoly()
and it does seem possible that the variables xl and xr could be passed
to ceil() without having been initialized.
The algorithm might actually preclude this but i haven't examined it that
closely.

>From what i've seen of the differences between sysV and BSD maths libraries
an unitialized variable, when passed to ceil(),
wouldn't do any harm under BSD and so might not be noticed.

by the way the value that ceil() blew up on was
	(double)0x7fffFFFFffffFFFF

thanks in advance for any help
rob

ps
if this is the result of some sort of overflow condition rather
than unitialized data then i'll have to bring the maths libraries
on our systems up to spec with BSD