Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!uicsrd!krause From: krause@uicsrd.UUCP Newsgroups: comp.sys.ibm.pc Subject: Re: Another TURBO C Bug?? Message-ID: <42900005@uicsrd> Date: Thu, 9-Jul-87 14:21:00 EDT Article-I.D.: uicsrd.42900005 Posted: Thu Jul 9 14:21:00 1987 Date-Received: Sun, 12-Jul-87 10:31:28 EDT References: <1239@ihlpm.ATT.COM> Lines: 63 Nf-ID: #R:ihlpm.ATT.COM:1239:uicsrd:42900005:000:3052 Nf-From: uicsrd.cs.uiuc.edu!krause Jul 9 13:21:00 1987 Written 7:55 am Jul 7, 1987 by joe@mdbs.UUCP in uicsrd:comp.sys.ibm.pc: >In article <1236@ihlpm.ATT.COM> kmh@ihlpm.ATT.COM (Kirk Hoyer) writes: >> >>When this program is compiled and executed (I used the tcc compiler), >>the values of f1 and f2 printed in the routine ffunc() are not the same >>as the values printed in the main program. >> >>The problem seems to go away if the declaration in the main program for >>ffunc() is changed as follows: >> >> float f1, f2, f3, ffunc( float, float ); > >I have run into this kind of problem with a lot of different compilers both >in the MSDOS environment and in the unix environment. The problems seem to >crop up when the compiler tries to support the IEEE floating point standard. >By default, all floating point numbers are converted to double precision >when passed through a subroutine call. The problem is that with ieee >floating point, doubles and floats have very little in common and it is a >non-trivial task to convert from one to the other. Now, in your example, >when you passed your floats to the function, they were converted to doubles. >If you look at your function, you decided to treat these doubles as floats. >This results in numbers that are different (remember that unlike vaxen, ieee >floats and doubles are different). This is analogous(sp?) to passing a short >to a routine which expects longs. In short, *I* claim that this isn't a bug, >rather it is a feature. You should use doubles if you want to let the compiler >use its default type. I have yet to find a compiler that supports ieee and >doesn't have this particular *feature*. > Joe Greer > ...ihnp4!pur-ee!mdbs!joe I think there may be a general misunderstanding about this point. Yes, it is true that K&R C requires floats to change to doubles on a function call, but it ALSO requires the callED routine to understand that it's "float" arguments are really coming in as "doubles". For a ref., check K&R, Appendix A, sect. 10.1, p. 205: C converts all float actual parameters to double, so formal parameters declared float have their declaration adjusted to read double. ANSI allows floats to be passed and received when a prototype is in scope for both the callER and callEE. But without prototypes, the compiler should default to doubles on both ends. I guess I don't see how this relates to IEEE reals. Besides Turbo C, I've used various compilers for MS-DOS/UNIX, including Lattice, Datalight, and Berkeley 4.x UNIX. I've never encountered a problem like in Turbo C (even in Datalight, about which I can't say enough negative things...but that's for another day). It may be a pain to convert from float to double and back, but the compiler has to do it. When I had this problem with Turbo C, I dug out various public-domain sources that used floating point--there was stuff written for everything from Aztec C (MSDOS) to the Amiga to Vaxen, and lots of it used floats as parameters. And without prototypes (it was older code). Anyway, that's my 2 cents. Cheers! James Krause