Mail Archives: djgpp/1998/05/19/15:00:42
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
- Raw text -