Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 01 Feb 2003 21:26:14 -0800
From:      Bakul Shah <bakul@bitblocks.com>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, Mark Murray <mark@grondar.org>, current@FreeBSD.ORG
Subject:   Re: Style fixups for proc.h 
Message-ID:  <200302020526.AAA04286@valiant.cnchost.com>
In-Reply-To: Your message of "Sat, 01 Feb 2003 18:55:36 PST." <3E3C88A8.B5D1171@mindspring.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302020526.AAA04286>