From owner-freebsd-questions Thu Dec 29 22:24:17 1994 Return-Path: questions-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id WAA13252 for questions-outgoing; Thu, 29 Dec 1994 22:24:17 -0800 Received: from cats.ucsc.edu (root@cats-po-1.UCSC.EDU [128.114.129.22]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id WAA13246 for ; Thu, 29 Dec 1994 22:24:16 -0800 Received: from scruz.ucsc.edu by cats.ucsc.edu with SMTP id WAA29459; Thu, 29 Dec 1994 22:24:04 -0800 Received: from osprey by scruz.ucsc.edu id aa15396; 29 Dec 94 23:20 PST Received: (from markd@localhost) by Grizzly.COM (8.6.9/8.6.9) id WAA27159; Thu, 29 Dec 1994 22:09:17 -0800 Date: Thu, 29 Dec 1994 22:09:17 -0800 From: Mark Diekhans Message-Id: <199412300609.WAA27159@Grizzly.COM> To: rivers%ponds@ncren.net CC: freebsd-questions@freebsd.org In-reply-to: <199412300233.VAA19033@ponds.UUCP> (message from Thomas David Rivers on Thu, 29 Dec 1994 21:33:21 -0500) Subject: Re: Behavior of sqrt on errors. Sender: questions-owner@freebsd.org Precedence: bulk >> On FreeBSD, >> >> sqrt (-3.0); >> >> generates a SIGFPE. On all other systems I have encountered, it calls >> matherr with a DOMAIN error. Can anyone more knowledgeable about the >> ANSI standard comment if this correct ANSI behavior or a bug? > From the sqrt(3) man page: > > The sqrt() function > returns the requested square root unless an error occurs. On the VAX or > Tahoe processor an attempt to take the sqrt() of negative x causes an er- > ror; in this event, the global variable errno is set to EDOM and a re- > served operand fault is generated. > > So, the man page implies this is working as designed. Thanks. I did see this, but all other Unix systems I have tried go to matherr. In fact, this has to do with software (Tcl) that is ported to virtually every Unix platform. In all of those implementations, either matherr or returning a NAN (not-a-number) value is used to report the error. I have seen the port of Tcl on ftp.freebsd.org, it does a fpsetmask(0) to prevent the exception, but then the errors are not reported back to the Tcl interpreter, instead invalid data is passed back. Since the next release of Tcl is in beta right now, I would like to come up with a solution that can be incorporated into the release. Anyone know anything about this? Mark