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