Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!mephisto!mcnc!duke!cameron!dukee!amr From: amr@dukee.egr.duke.edu (Anthony M. Richardson) Newsgroups: comp.sys.amiga.tech Subject: Re: Manx 5.0 problems Message-ID: <666@cameron.cs.duke.edu> Date: 28 Feb 90 03:51:47 GMT References: <5790.25ea4d1b@vax1.tcd.ie> Sender: news@cameron.cs.duke.edu Lines: 109 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