Sender: nate AT cartsys DOT com Message-ID: <3564F35C.A0FBA509@cartsys.com> Date: Thu, 21 May 1998 20:39:08 -0700 From: Nate Eldredge MIME-Version: 1.0 To: Eli Zaretskii , Eric Rudd , djgpp AT delorie DOT com Subject: Re: Code to Fix sinh() in libm.a References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Eli Zaretskii wrote: > > On Tue, 19 May 1998, Eric Rudd wrote: > > 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. > [deletia] > > > 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. > What about this idea: create another library which provides all the same functions, but is fast instead of being ANSI-compliant. Perhaps call it libfm.a. Then things that wanted ANSI could use -lm (or alternatively libm's functions could be plopped directly into libc), while game programmers etc. could use -lfm. I realize it would be more work, but it could give the best of both worlds. -- Nate Eldredge nate AT cartsys DOT com