Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!newstop!sun!amdcad!mozart.amd.com!proton!tim
From: tim@proton.amd.com (Tim Olson)
Newsgroups: comp.lang.c
Subject: Re: float to double pain
Message-ID: <1990Dec12.003546.15874@mozart.amd.com>
Date: 12 Dec 90 00:35:46 GMT
References: <4268@ritcsh.cs.rit.edu> <9919@hydra.Helsinki.FI> <1990Dec11.173043.8171@mozart.amd.com>
Sender: usenet@mozart.amd.com (Usenet News)
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Austin, TX
Lines: 40

In article <1990Dec11.173043.8171@mozart.amd.com> tim@amd.com (I) write:
| | >t(f1)
| | >float f1;
| | >{
| | >	check(&f1);
| | >}
| | 
| | For old-style function definitions arguments of type float are silently
| | rewritten to be of type double.
| 
| 	Correct.
| 
| | So &f1 is actually a pointer to a
| | double, which is inconsistent with check's expectation of a pointer to a
| | float.
| 
| 	This isn't right -- type-rewriting does not take place for
| 	pointers; &f1 is still a pointer to a float.

After writing this, it was pointed out to me by
wald@theory.lcs.mit.edu (David Wald) that I missed the fact that f1
was itself passed in as a parameter of type "float" with an old-style
declaration -- I had mistakenly thought it was declared locally.

To get back to the real question, then:
K&R compilers tended to keep arguments of type "float" silently
promoted to doubles, causing the problem that the original poster
pointed out.  ANSI-compliant compilers, however, must convert each
incoming argument to the type of its corresponding parameter (as if by
assignment).  This solves the type-mismatch problem, and makes much
more sense, as well!

Note that this is not limited to floats/doubles; "narrowing" must
occur for all types that have default widening rules, like char/short
-> int.  However, most K&R C compilers do the right thing with these.

--
	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)