>> [...K&R definitions vs prototype definitions...]
> The big problem with K&R style is it assumes everything fits in an
> int.

Not really; you can pass around large types in K&R style.  What you
don't get is the implicit cast from the actual argument's type to the
formal parameter's type.  Provided you're careful that the actual
argument's type (after the default promotions) is compatible with the
formal parameter's type (ditto), you're fine - whether or not it fits
in an int.

Coders used to the implicit casts provided by prototype declarations
are likely to find the necessary discipline difficult. :-/

> I'm not 100% sure what happens if you have an ANSI prototype and a
> K&R function start.

I'd have to check with a real C maven to be sure.  But I think that
provided the types in the prototype match the formal parameter types,
and those types are compatible with what they turn into after the
default promotions, you're OK - and that if this doesn't hold, it is an
error (though I'm not sure whether you get implementation-defined or
undefined behaviour).

In gcc, the prototype declaration sometimes silently overrides the
old-style definition: "in GNU C, a function prototype argument type
overrides the argument type specified by a later old-style definition
if the former type is the same as the latter type before promotion"
(quoted from the extend.texi from 3.1; the extend.texi from 1.4T has
wording that looks identical to an eyeball compare).  I'm not sure
whether I think this is a feature or a misfeature.  (I think the lack
of an option to disable it is definitely a misfeature.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B