calling the acos() function in the math library with illegal values ( say -2.0 ) causes a floating exception core dump. /usr/lib info: # ls -l libm.* -r--r--r-- 1 bin bin 123388 Nov 22 05:14 libm.a -r--r--r-- 1 bin bin 165021 Nov 22 05:14 libm.so.2.0 # cksum libm.* 3164276670 123388 libm.a 3263430048 165021 libm.so.2.0 Fix: Unknown. How-To-Repeat: Try running this an linking with -lm: #include<stdio.h> #include<math.h> main() { acos(-2.0); }
Responsible Changed From-To: freebsd-bugs->bde bde is Mr. Math. I have verified that the problem still persists.
I believe that this is what is suppose to happen... you use SIGFPE to trap these errors and possibly rerun the function after correcting the problem.... acording to the math(3) man page an exception is suppose to occure on invalid values... so this is really a non-error correct? and this pr should be closed... i.e. acos(-2.0) is suppose to generate a SIGFPE else it isn't doing what math(3) says it will do... John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix)
>I believe that this is what is suppose to happen... you use SIGFPE to >trap these errors and possibly rerun the function after correcting the >problem.... acording to the math(3) man page an exception is suppose to >occure on invalid values... > >so this is really a non-error correct? and this pr should be closed... > >i.e. acos(-2.0) is suppose to generate a SIGFPE else it isn't doing what >math(3) says it will do... As the default behavior, this causes a great amount of pain when porting software to BSD. No other system that I know of works in this manner. Its a royal pain for things like Tcl and other interpreters that want to check errno after calling a math function. Mark
>>I believe that this is what is suppose to happen... you use SIGFPE to >>trap these errors and possibly rerun the function after correcting the >>problem.... acording to the math(3) man page an exception is suppose to >>occure on invalid values... No. math(3) says "NOTE: An Exception is not an Error unless handled badly". It doesn't say that the default FreeBSD handling is always bad :-]. >As the default behavior, this causes a great amount of pain when porting >software to BSD. No other system that I know of works in this manner. >Its a royal pain for things like Tcl and other interpreters that want to >check errno after calling a math function. BSD's libraries are both advanced and broken here. The old libm almost never sets errno. Instead, for domain errors, it attempts to return a NaN and attempts to set the IEEE exception bit for invalid operand. These attempts, especially the setting of the exception bit, are sometimes broken by gcc's lack of support for IEEE floating point and libm's faith in the compiler's lack of optimization. The new libm (msun) has support for setting errno, but for various reasons this support is not enabled by default in FreeBSD. Bruce
On Mon, 10 Feb 1997, Mark Diekhans wrote: > >I believe that this is what is suppose to happen... you use SIGFPE to > >trap these errors and possibly rerun the function after correcting the > >problem.... acording to the math(3) man page an exception is suppose to > >occure on invalid values... > > > >so this is really a non-error correct? and this pr should be closed... > > > >i.e. acos(-2.0) is suppose to generate a SIGFPE else it isn't doing what > >math(3) says it will do... > > As the default behavior, this causes a great amount of pain when porting > software to BSD. No other system that I know of works in this manner. > Its a royal pain for things like Tcl and other interpreters that want to > check errno after calling a math function. well... it turns out that this is the IEEE 754 Spec that libm if following... I don't think the FreeBSD team would mind adding a free ANSI C compatible math lib to the source tree... do you have access or knowledge of one? guess the real pr is is not having an ANSI C math lib? thanks for the clarification... ttyl.. John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix)
State Changed From-To: open->closed In a recent discussion this was again proposed as to be changed, but wasn't. Doug White mentions the following as a solution to problems with FPE's and netscape: Did you use the port? This is a common Linux-ism. Linux masks all FPU exceptions by default, where FreeBSD does not. The offending calls simply need to be bracketed with fpgetmask()/fpsetmask() calls. Doug White
As Bruce suggests, this bug report is the same as 105. ---------- Forwarded message ---------- Date: Mon, 19 Jul 1999 20:05:40 +1000 From: Bruce Evans <bde@zeta.org.au> To: n_hibma@FreeBSD.org Subject: Re: misc/229: acos() core dump >Synopsis: acos() core dump > >State-Changed-From-To: open->closed This should be left open, or marked superseded/preceded by i386/105. >This is a common Linux-ism. Linux masks all FPU exceptions by default, >where FreeBSD does not. The offending calls simply need to be bracketed >with fpgetmask()/fpsetmask() calls. FreeBSD is not compatible with Standard C here. The Standard requires all Standard math functions to not produced any externally visible exceptions. Bracketing the offending calls is very slow and doesn't actually work unless there is no offense or the closing bracket is omitted so that exceptions remain masked (it just delays delivery of a SIGFPE). OTOH, the Standard doesn't require anything for FP exceptions outside of math functions (the behaviour is undefined). Defaulting to delivery of a SIGFPE is useful for finding bugs in the 99.9% of programs that don't actually understand IEEE arithmetic. E.g., PR12611 could be "fixed" by masking overflow execptions. `jot -w %d 3 3000000000' would then produced 3 identical numbers (the single result of the default for overflow on conversion of double to long) instead of (int)3000000000, (int)3000000001, etc. Bruce