🚀 go-pugleaf

From article <5790.25ea4d1b@vax1.tcd.ie>, by rwallace@vax1.tcd.ie:
> 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).
>> 

I pointed out that this is indeed a bug, a point to which Russell takes
exception ...

> 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. 

This is true.

> 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.

This is false.  test_func does not "expect an actual char". The function

    	 	int test_func(y)
     		char y;
     		{ printf("X = %c\n",y); }

should be implemented by the compiler as 

    	 	int test_func(y)
     		int y;
     		{ printf("X = %c\n",(int)(char)y); }
  
(I don't have K&R with me, but see page 228 of Harbison and Steele for a
reference.)  By your logic, the function 

		float test(x)
		float x; 
		{return(x); }

would HAVE to be defined as

		double test(x)
		double x;
		{return(x); }

which is certainly wrong. (The fact that, in the first case, x is actually
converted to double when test is called is not, and should not be of
concern to the programmer. The compiler handles this for you.)


>> 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.

As I stated in the previous response, according to draft ANSI this is a
bug. Draft ANSI stated that the function prototype must agree with the
widened parameter types of any old-style definitions.  This means that
the correct prototype for

		float test(x,c,d)
		float x; char c; short d;
		{ return(10.); }

is
		double test(double, int, int);

Would someone please tell me whether or not this made it into the standard?

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

Tony Richardson
amr@dukee.egr.duke.edu