From: Eric Rudd Newsgroups: comp.os.msdos.djgpp Subject: Re: Code to Fix sinh() in libm.a Date: Tue, 19 May 1998 10:43:11 -0500 Organization: CyberOptics Lines: 89 Message-ID: <3561A88F.A092086A@cyberoptics.com> References: Reply-To: rudd AT cyberoptics DOT com NNTP-Posting-Host: rudd.cyberoptics.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Eli Zaretskii wrote: > > This is incorrect. First, matherr isn't a Borland-ism, it is > supported by all Unix boxes I've seen (Borland are just trying to be > compliant here). And second, DJGPP *does* have matherr, but only in > libm.a, so you need to link with -lm to get it. I looked for it with "info libc a matherr", but didn't find it there, so concluded that it didn't exist. > > but on the x87, I think there are more > > advantages than disadvantages in silently returning infinity, since the > > x87 knows how to use infinity in further arithmetic computations. > > I see no contradiction here. Setting errno doesn't prevent any > program from continuing with its business and ignoring the value of > errno. True, but there's a price to be paid for this, both in terms of code complexity and execution time. My philosophy is that users who don't need such error trapping shouldn't be forced to pay the time penalty; those who do can test args before calling the functions. I get the impression that there are a lot of game programmers using DJGPP, who are hungry for every bit of speed they can get. Right now, they don't have much of a choice: either use libc, with its non-ANSI behavior and accuracy problems, or use libm and put up with a big slowdown (I'm assuming the use of the new libm -- the current one has accuracy problems, too). I had envisioned retaining libm as an option for those who need the best possible error-handling, but upgrading libc to a lean-and-mean (but accurate and ANSI-compliant) library for the rest of us. > IMHO, a general-purpose library should not second-guess what is > expected by its caller. I can easily think about the cases where an > application *does* want to know about the overflow in cosh. Even > underflows are sometimes important to be noted. (sigh) There's always some guessing about what the user might want. You write the routine to conform to existing specifications (ANSI), document its behavior, and let those with special requirements do additional testing. But this whole thread has veered off from what initially prompted me to jump in -- that there were serious *accuracy* problems both with libc and libm. IMHO, that is a *far* more serious problem than any of this error-handling stuff. I had wanted to upgrade the libc routines to be uncompromisingly accurate, while maintaining their considerable speed advantages, but the discussion has drifted off. I'm feeling a bit frustrated. > > Any program that makes assumptions about infinity being trapped has > > questionable portability, anyway. > > I fail to understand this argument. What's non-portable about > assuming that errno can be set when I call, say, exp with an argument > which can be large? Because ANSI doens't *require* it. If your program *must* work under all compilers, and it generates arguments which produce implementation- defined results, then it *must* test arguments itself, since it can't assume that the math functions do this. > > but I feel that > > functions that do not appear in the ANSI standard should not be > > prototyped in math.h, since there is a namespace pollution issue. > I don't see any conflict here. The non-ANSI functions are prototyped > under #ifndef __STRICT_ANSI__, which means that if you compile with > -ansi, GCC won't see those prototypes. Using -ansi (or its > equivalents in other compilers) is the standard way of disabling > extensions which might invade the ANSI namespace. For that matter, > any program that wants to be strictly conforming should be always > compiled with -ansi. I agree that strictly-conforming programs won't be in any trouble with the -ansi switch; but unfortunately if you use -ansi it kills other useful ANSI extensions as well. For instance, I ported over some code from Borland a long time ago, which used // comments and also declared a static int with the name "y0". This wouldn't compile under DJGPP, since "y0" was prototyped in the math.h header as a double function. I can easily foresee a situation where the someone might add functions to the libm library that would break existing (though non-ANSI) code. My vote would be to put the non-ANSI functions in some other header, say "mathext.h", or enable them in math.h only when some macro is defined, say -DMATHEXT. -Eric Rudd rudd AT cyberoptics DOT com