In article <199507240250.TAA07151@Kowhai.Stanford.EDU> jonathan@dsg.stanford.edu (Jonathan Stone) writes:
>
>>Does this mean *not* using prototypes at all would be more efficient?
>>I thought it to mean an implied ellipsis were there.  Isn't it so?
>

On a different subject. I have finished cleaning up:


db
kern
dev
vm
miscfs

and parts of net....

They all now compile with -Wall -Wstrict-prototypes.

I found only one serious bug [inconsistent calling of a routine in
miscfs/nullfs I think].

It is not that tough to do as long as you are willing to make some concessions
to account for the fact that c++ is not polymorphic:

1. all system calls are int (*) __P((struct proc *, void *, register_t *));
2. all vfs call are int (*) __P((void *));

Then

int
read(p, uap, r)
	struct proc *p;
	struct read_args *uap;
	register_t *r;
{

becomes:

int
read(p, v, r)
	struct proc *p;
	void *v;
	register_t *r;
{
	struct read_args *uap = v;

Similarly for the vfs calls and c is happy.

I think that strict-prototypes and missing-prototypes is a big win, because
it forces people to write correct prototypes instead of cheating by making
K&R forward declarations, and that the penalty we pay for not having
polymorphism is not that significant.

christos