Mail Archives: djgpp/1998/05/20/05:15:06
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 <math.h>
[...]
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''.)
- Raw text -