Mail Archives: djgpp-workers/1999/06/23/05:37:13
On Tue, 22 Jun 1999, Eric Rudd wrote:
> (Note that I
> am making a distinction between mnemonics, such as "fdivr", which
> one submits to the assembler, and opcodes, which the assembler
> emits. There's not a one-to-one correspondence here, because of
> assembler and Intel doc bugs!)
IMHO, somebody should at least tell this to the GNU Binutils
maintainers. From your description I understand that we cannot even
be sure that Binutils 2.9.1 solves this problem.
> I started to edit stubs.h to include the
> non-ANSI routines, but stopped when I noticed that other non-ANSI
> functions, such as hypot, are not even in stubs.h.
The only functions that should be in stubs.h are those which are
called by ANSI or Posix functions. I don't think hypot is one of
them.
> I'm not sure how we should clean up this mess.
I don't think your versions of math functions add any mess at all. In
fact, I think you shouldn't need to edit stubs.h at all, unless some
of the ANSI/Posix functions that you wrote call non-ANSI/non-Posix
functions. Since your code usually doesn't CALL anything, there
should be no need for you to bother about the stubs.
> What should we do about the stubbing and prototyping of these
> various functions?
The only concern is not to pollute the namespace of a program that
wants to use ANSI- or Posix-only functions (or other external
symbols).
The headers are written so that if you invoke the compiler with the
-ansi or -posix switch, the non-ANSI/non-Posix parts of the headers
are hidden behind #ifdef's like __STRICT_ANSI__ and _POSIX_SOURCE
(which gcc defines as the result of the above switches). The library
must make sure that if the program only calls ANSI or Posix function,
none of the non-ANSI/non-Posix functions will be pulled from the
library, *unless* those non-standard functions begin with two
underscores. Names with two leading underscores are reserved by the
ANSI/Posix standards ``for the library implementation''.
The reason to avoid the namespace pollution is that an application
that uses strict standard compliance is entitled to define its own
external sysmbols with any name except those reserved by the
standards. The standards reserve all the names of the standard
library functions, and those which begin with two underscores or with
an underscore and a capital letter.
A program that itself calls non-standard function is not of our
concern here: it is already in trouble with the standards.
The whole point of the stubs is to avoid using non-standard external
names, but also avoid the need to have two identical library functions
that do the same, in case some non-conforming program wants a
non-standard function such as pow2.
Did the explanation above make any sense?
On a practical side, the prototypes of the non-standard functions
should go into the non-standard parts of the headers. But you don't
have to bother about this, since I already made the necessary changes
in math.h and libm/math.h; I will check the new versions into the CVS
when I check in the modified sources.
> 6. There was some question about the behavior of ldexp, but I can't
> find anything wrong with it.
My concern was the same as in the case of hypot: if the result
overflows a double (but not a long double), it seemed to me that the
code would not set errno. Perhaps I missed something.
> If there are any other issues I have overlooked in this list, please
> let me know. If not, I'll upload the new routines.
Please upload them.
Is the docs I sent to you correct in describing the behavior of the
new version (except for the comment about the rounding mode which I
understand I can remove)?
And thanks for the hard work.
- Raw text -