May prototypes be required for lib functs

[David Brooks]

(this followup adds comp.lang.c to comp.std.c)
In article <13759 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:

|> Furthermore, any function need not be declared using prototype ("new-
|> style") syntax if its parameters have already-default-widened types
|> (as I think all the standard library functions do).  And any function
|> need not be declared at all if it returns type int and its parameters
|> have already-default-widened types.

This loses some of the benefits of prototypes.  But if your parameters
don't have already-widened types, you must beware of the following
situations:

Define your callee with a narrow parameter or two, and accidentally
leave out the prototype from the caller.  Your program breaks.  We all
know this, right?  Not necessarily.

Build a library using prototypes and narrow parameters, and put the
binary out on the streets.  Your customers had better use prototypes
in their application code, which means you have to insist they build
with a prototyping compiler.  Reasonable.

It gets worse.  There are some overly-helpful compilers out there
which do the widening anyway, prototype or no.  This is quite
consistent with the ANSI rules; it works so long as the caller and
callee agree about it.  So you do all your program development with
that compiler, test it up the wazoo, and put the source out on the
streets.  But you got the prototypes mixed up - either you misspelt
the function name in a header file or you left a #include out of a
source.  A paying customer points a less-helpful compiler at it (or
the same compiler, built differently), and it breaks in obscure ways.

Of course, such a compiler would produce at least a comment when it
encounters a default-declared procedure.  But prudence is beginning to
suggest that I balance the advantages of decent parameter type
checking against handling non-reproducible-in-house parameter-passing
bugs.

(people who meet me in other newsgroups know what I'm talking about).
-- 
David Brooks				dbrooks at osf.org
Systems Engineering, OSF		uunet!osf.org!dbrooks
Experience Hackvergnuegen!