> Technically, the compiler doesn't need prototypes at all; they > are merely a band-aid for the compiler vendors, who did not want > to have to deal with changing object file format.
IMHO the value of prototypes is in documenting a function interface rather than for the vendors. Compilers of languages such as Haskell must be smart enough to derive type information but even there one is encouraged to specify the type of a function "for documentation purposes". Even with prototypes in the language, a type checking smart linker would be immensely helpful (which, AFAIK, no vendor has provided as yet). As it is, you can have struct foo {int x;} extern int f(struct foo); in one file and struct foo {int x,y;} int f(struct foo g) { return g.y; } in other, the linker will happily assume extern f in the first file refers to the one in the second. > In fact, it should > ignore tokens to the coma or closing parenthesis, and not be bitching > in the first place. Not quite. Consider something like // *product = *mat1 * *mat2 int matrix_multiply(int n, int k, int m, double (*product)[n][m], double (*mat1)[n][k], double (*mat2)[k][m]); This is legal C99 and certainly legal gcc C! Apropos `style fixups', may be the right thing to do is to _uglify_ global variable names rather than parameter names! Lisp/Scheme programmers use a *<var-name>* convention for global data objects (such as *argv*) which has this very good side effect of reducing global var use and if they are used, they are very easy to spot. A similar uglification of kernel globals would lead to a real cleanup! But I am not holding my breath.... -- bakul To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message