Mail Archives: djgpp/1998/05/21/23:40:31
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
- Raw text -