jdc@naucse.UUCP (John Campbell) (08/25/87)
I'm not sure any comp.lang.c netters really care about the compiler
I have been using (VMS latest release), but it seems to me the following
implementation of prototypes is pretty screwy...
From the VMS Guide to VAX C manual (VMS 'C' version 2.3-024):
If the data type of an argument in a function call does not match
the prototype, VAX C attempts to perform conversions. If the
mismatched argument is assignment compatible with the prototype
parameter, VAX C converts the argument to the data type specified
in the prototype, according to the parameter and argument conversion
rules (...).
If the mismatched argument is not assignment compatible with the
prototype parameter, the action generates the appropriate error
message and the results are undefined.
Here is a listing (with /MACHINE interspersed) of a program that compiles
without any complaints:
1
2 void screwy (int aa, char **bb);
3 main()
4 {
main:
.entry main,^m<r2,r3>
subl2 #4,sp
jsb C$MAIN
5 1 int a;
6 1 float b;
7 1
8 1 screwy (a, b);
cvtfl r2,-(sp)
pushl r3
calls #2,FARM_IT
9 1 }
movl #1,r0
ret
10
11 void screwy (a, b)
12 int a;
screwy:
.entry screwy,^m<>
subl2 #4,sp
13 float b;
14 {
15 1 b = a;
cvtld 4(ap),8(ap)
16 1 }
ret
Changing the definition of ``screwy'' to use the new style function
definition with this compiler (eg void screwy (int a, float b) {})
will cause the compiler to give an error message about mismatched
arguments (which is what I wanted all along).
Questions:
Should old and new style definitions yield different behaviors?
Is this the expected way to implement prototypes?
Are prototypes all that useful in such an implementation?
Is it really correct to CVTFL in the guise of "assignment compatibility"?
If *anyone* would care to defend or attack the documentation or actual
behavior of this compiler's use of prototypes, I would love to read all
about it.
jdc -- ..arizona!naucse!jdc 602-523-6259
(DEC, the inventors of runoff, use TeX!)gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/26/87)
In article <434@naucse.UUCP> jdc@naucse.UUCP (John Campbell) writes: >Should old and new style definitions yield different behaviors? They do in many circumstances. The next X3J11 public review package should have more examples to clarify this. >Is this the expected way to implement prototypes? More or less, except that considering a (float) to be assignment-compatible with a (char**) seems to stretch matters a bit. I think the documentation was pretty accurate, but the rules on this have changed somewhat, so you should avoid pushing the compiler into the dark corners of the spec in this regard. If you're going to use prototypes, use them everywhere and don't depend on the automatic parameter coercion (it should work in all "sane" cases, but I think it's better style to use explicit casts, to let the future code reader know what is going on and that you really did intend it).
drw@cullvax.UUCP (Dale Worley) (08/27/87)
jdc@naucse.UUCP (John Campbell) writes: > Should old and new style definitions yield different behaviors? Well, if your function prototype doesn't agree with the definition (whether the definition is old style or new), the code is definitely erroneous. The code you presented: 2 void screwy (int aa, char **bb); 11 void screwy (a, b) 12 int a; 13 float b; { ... } should be flagged with an error. If the compiler doesn't, it's deficient. > Are prototypes all that useful in such an implementation? Definitely, yes. It's the only way you can have the compiler check function calls in one source file with function definitions in another source file. > Is it really correct to CVTFL in the guise of "assignment compatibility"? Well, it's correct according to ANSI C. But what else could the programmer mean? If the argument *has* to be 'float', and user has written '1', what could possibly be meant? > (DEC, the inventors of runoff, use TeX!) Not quite! runoff existed on CTSS (the world's first timesharing system). Dale -- Dale Worley Cullinet Software ARPA: cullvax!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw Apollo was the doorway to the stars - next time we should open it. Disclaimer: Don't sue me, sue my company - they have more money.