From owner-freebsd-current Sat Feb 1 21:26:30 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8501837B401 for ; Sat, 1 Feb 2003 21:26:28 -0800 (PST) Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A36143F79 for ; Sat, 1 Feb 2003 21:26:28 -0800 (PST) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by valiant.cnchost.com id AAA04286; Sun, 2 Feb 2003 00:26:14 -0500 (EST) [ConcentricHost SMTP Relay 1.15] Message-ID: <200302020526.AAA04286@valiant.cnchost.com> To: Terry Lambert Cc: Matthew Dillon , Mark Murray , current@FreeBSD.ORG Subject: Re: Style fixups for proc.h In-reply-to: Your message of "Sat, 01 Feb 2003 18:55:36 PST." <3E3C88A8.B5D1171@mindspring.com> Date: Sat, 01 Feb 2003 21:26:14 -0800 From: Bakul Shah Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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 ** 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message