Path: utzoo!attcan!uunet!mcsun!ukc!tcdcs!swift.cs.tcd.ie!vax1.tcd.ie!rwallace
From: rwallace@vax1.tcd.ie
Newsgroups: comp.sys.amiga.tech
Subject: Re: Manx 5.0 problems
Message-ID: <5790.25ea4d1b@vax1.tcd.ie>
Date: 27 Feb 90 09:49:15 GMT
References: <1990Feb24.005652.971@oresoft.uu.net> <655@cameron.cs.duke.edu>
Organization: Computer Laboratory, Trinity College Dublin
Lines: 64

In article <655@cameron.cs.duke.edu>, amr@dukee.egr.duke.edu (Anthony M. Richardson) writes:
> In article <35312@grapevine.EBay.Sun.COM> golson@grapevine.EBay.Sun.COM (Greg Olson) writes:
> :Hi everyone.  I've been using Manx 5.0 for a little while, and thought I'd 
> :post a few problems I've run across.
> 
> [a few problems]
> 
> :	3) (Probably the most frustrating)  It seems that Manx doesn't handle
> :	using new style prototyping and old style function definition parameter
> :	promotion correctly.  For instance:
> :
> :		int test_func(int);	/* HAS TO BE INT FOR ANSI */
> :		main(){test_func('X');}
> :		int test_func(y)
> :		char y;
> :		{ printf("X = %c\n",y); }
> :
> :	will not print X to the screen (as it should, by my understanding of
> :	ANSI promotion rules for new-style prototype/old style function
> :	definitions).
> 
> According to the second edition of Harbison and Steele - specifically
> section 11.3.5 - which discusses DRAFT proposed ANSI C,
> 
>  "A function defined in traditional form does not introduce a prototype,
>   but if a prototype exists because of a previous declaration, the 
>   widened parameter declarations in the definition must agree exactly
>   with the prototype and that prototype remains in effect."
> 
> and so the above would indeed be a bug.  I don't have a copy of the
> standard, but believe this made it in. (Can anyone verify this?)

You would be right if "char y" had been, say, "float y", in which case the
compiler would have passed an int as it had been told to do but test_func would
be expecting a float, so the code and not the compiler would be at fault.
HOWEVER, in both K&R and ANSI C all chars passed as parameters are expanded to
int. Therefore test_func should actually be expecting an int, which it would
then convert back to a char (actual conversion might not be necessary on the
68000 but this is neither here nor there). BUT test_func expected an actual
char. Therefore this is a compiler bug with regard to both K&R and ANSI
definitions of C.
 
> By the way, I don't think that Lattice does this correctly
> either (assuming the above is in the standard). If a prototype exists
> for a traditional form definition, then conversions are done according to
> the prototype.  This means that the example above will work, as will,
> 
> 		int test_func(char);
> 		main(){test_func('X');}
> 		int test_func(y)
> 		char y;
> 		{ printf("X = %c\n",y); }
> 
> This is certainly programmer friendly behavior, but not correct behavior.
> (In this latter case the compiler should at least give a warning about
> a mismatch between the declaration and the definition.)

True, at least a warning would be appropriate here, but I thought all ANSI
compilers did this i.e. not relate function prototypes to old-style formal
parameter declarations.

"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
rwallace@vax1.tcd.ie