Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!amdahl!rtech!jas
From: jas@rtech.UUCP
Newsgroups: comp.lang.c
Subject: Function prototypes (was: miscellaneous unrelated stuff)
Message-ID: <796@rtech.UUCP>
Date: Thu, 30-Apr-87 12:33:14 EDT
Article-I.D.: rtech.796
Posted: Thu Apr 30 12:33:14 1987
Date-Received: Sat, 2-May-87 07:01:49 EDT
References: <18346@ucbvax.BERKELEY.EDU> <7973@utzoo.UUCP>
Reply-To: jas@rtech.UUCP (Jim Shankland)
Organization: Relational Technology, Alameda CA
Lines: 24
Summary: What's wrong with function prototypes?


Henry Spencer (utzoo!henry) notes in passing:

> [Function prototypes] have other problems, and I'm not sure they were a
> good idea....

This got me curious:  what are the problems with function prototypes?
The only one I can think of is that an implicit coercion will not be
done when there is no function prototype in scope.  I would resolve
that by requiring compilers to emit a fairly strongly worded warning
whenever a program called a function without a prototype in scope.  (If
we were designing C from scratch at this point, I'd outlaw it
altogether; but we're not.)  I see nothing wrong with implicit coercion
per se, as long as the coercion is well defined.  Implicit coercion of
one pointer type to another should minimally elicit a warning, like
pcc's when doing this implicit coercion on assignment.

Are there additional arguments against function prototypes?  If so,
what are they?
-- 
Jim Shankland
 ..!ihnp4!cpsc6a!\
                  rtech!jas
..!ucbvax!mtxinu!/