Date: Wed, 23 Jun 1999 11:31:39 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Eric Rudd cc: djgpp-workers AT delorie DOT com Subject: Re: libm sources from cyberoptics In-Reply-To: <376FB68E.671D8763@cyberoptics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.