golson@grapevine.EBay.Sun.COM (Greg Olson) (02/23/90)
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.
1) mktemp seems to be missing from c.lib and all permutations(c16.lib,
etc.) Sounds kind of like realloc from 3.6, right?....
2) Though format.o is an object module archived in c.lib, try writing
a small program which tries to access format(). (something like
main(){format();}). I think you'll find that you get an unresolved
error at link time. Doing a cnm on format.o, it seems that the function
is called _format, but I'm really not sure. Got a message into Manx
about this.
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 have a few mail messages into Manx, but haven't heard word one as of yet.
Can anyone verify/dispute these?
--Gregdan@oresoft.uu.net (Daniel Elbaum) (02/24/90)
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 have a few mail messages into Manx, but haven't heard word one as of yet.
:Can anyone verify/dispute these?
You give test_func an int, but it only takes a char. The prototype
for test_char() does not specify any conversion to int to be
performed at the point of the call. So an int gets passed, and part
of that int is what y refers to. There's never a guarantee that
mixing declaration styles as in this example will work the way you
expect. The danger is that sometimes it will.
--
Mine is red, round, and has three buttons. --B. Stroustrup
({uunet,tektronix,reed,sun!nosun,m2xenix}!oresoft!(dan)@oresoft.uu.net)amr@dukee.egr.duke.edu (Anthony M. Richardson) (02/25/90)
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 have a few mail messages into Manx, but haven't heard word one as of yet.
:Can anyone verify/dispute these?
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?)
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.)
Tony Richardson amr@dukee.egr.duke.edurwallace@vax1.tcd.ie (02/27/90)
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
amr@dukee.egr.duke.edu (Anthony M. Richardson) (02/28/90)
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
pfalstad@phoenix.Princeton.EDU (Paul John Falstad) (03/01/90)
I've found several bugs--I can't remember them all now, but I posted them
on the Manx BBS, with code fragments that demonstrate the bugs. I am
pretty sure they're bugs and not my mistakes.
For example, main(){printf("%s","A\x20" "B");} does not print "A B",
as expected. It prints a single space. The string concat doesn't work
properly with the escape character, I guess.
Also, enum's (or typedef enum's) in structure definitions can cause problems.
If you initialize a structure with enums in it, and then try to read the
initialized values, you get garbage. Also, I think there were problems
with passing enums as arguments to functions.
I also got a few internal errors with the X->Y++ and X->Y += Z constructs.
The code fragments, anyway, are on the Manx BBS, 201-542-2793.