Date: Wed, 20 May 1998 12:11:36 +0300 (IDT) From: Eli Zaretskii To: Eric Rudd cc: djgpp AT delorie DOT com Subject: Re: Code to Fix sinh() in libm.a In-Reply-To: <3561A88F.A092086A@cyberoptics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 19 May 1998, Eric Rudd wrote: > I looked for it with "info libc a matherr", but didn't find it there, so > concluded that it didn't exist. libm.a isn't documented at all. I hope this will change in v2.02. I have some preliminary docs of the current matherr functionality in v2.01, and I can send it to you if you want. > 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 disagree with this philosophy. I don't think you can get away with putting the burden on application code. An application doesn't always know what functions will be called internally by some complicated FP library, so they won't always know how to test the arguments. > 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. This is an okay solution, provided that the lean-and-mean version is indeed ANSI-compliant. However, ANSI compliance actually requires errno to be set; see below. > 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. I'm truely sorry about your frustration; I have never meant to cause it. We were discussing an issue and I expressed my views about it. But they are only my views, no more, no less; please do not confuse them with some kind of dictate. I cannot and I won't dictate anything to somebody who volunteers to make a contribution to DJGPP. You don't have to agree with me if your views are different. You certainly shouldn't feel frustrated about such disagreement. And you shouldn't see our disagreement as a reason not to do whatever you think should be done to make DJGPP better; if I said anything that could be interpreted in this way, I apologize. It is true that your contribution will have to pass a peer review by several people who work on DJGPP development, but I'm not talking on their behalf, and I don't have any final saying on these matters. So please feel free to go on with your project even if it contradicts my views. > > 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. My references indicate that ANSI *does* require errno to be set, at least in some cases. I attach several excerpts at the end of this message. I think that those cases where the standard doesn't require errno to be set, but it can be set with no significant runtime penalty, it should be done. For example, testing the result for being a NaN or an Inf, and setting errno if it is, doesn't seem like a large penalty to me. > 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. A program that uses non-ANSI extensions cannot be a cause for complaining about other extensions. IMHO, the ANSI namespace pollution is only an issue in ANSI-conforming programs, and -ansi was designed for them. FWIW, I'm not aware of *any* C library which doesn't have non-ANSI extensions in its headers, and the only way for preventing them from polluting your namespace is to use -ansi or its equivalent. > I can easily foresee a situation where the someone might add > functions to the libm library that would break existing (though > non-ANSI) code. Having functions in a library is not a problem: library functions don't get linked in if the application includes functions by the same name, since typically the linker sees the library after all of the application object files. Only the prototypes are the problem, since they are all visible at compile time. > 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. This will break many existing programs which rely on the additional functions (since they are supported by many platforms) without any additional definitions. But if you feel strongly about this, you need to convince DJ Delorie to make this change in a future DJGPP release. ------------------ From ANSI C Standard ----------------------------- 7.5 Mathematics [...] 7.5.1 Treatment of error conditions [...] For all functions, a *domain error* occurs if an input argument is outside the domain over which the mathematical function is defined. [...] On a domain error, the function returns an implementation-defined value; the value of the macro EDOM is stored in `errno'. Similarly, a *range error* occurs if the result of the function cannot be represented as a `double' value. If the result overflows [...], the function returns the value of the macro HUGE_VAL [...]; the value of the macro ERANGE is stored in `errno'. If the result underflows [...], the function returns zero; whether [...] `errno' acquires the value of the macro ERANGE is implementation-defined. ---------------------------------------------------------------------- The standard then goes on to define domain error conditions for acos, asin, log, pow, sqrt, and possibly, atan2 and fmod; and range error conditions for cosh, sinh, exp, and, possibly, ldexp, log, log10, and pow. (``Possibly'' means that the Standard says the error ``may occur''.)