ANSI C prototypes

[Steve Resnick]

In article <151 at nazgul.UUCP> bright at nazgul.UUCP (Walter Bright) writes:


[Stuff Deleted]

>/The point is, why should I have to tell the compiler twice the type of
>/auxiliary_func? The prototype should be necessary only if I make a
>/forward reference to make it easier for the compiler to check types in a
>/single pass. I think the function definition tells unambiguously the
>/types, so I should not have to watch warnings such as "function
>/definition used as a prototype" (Microsoft C 5.1).
>
>In Zortech, the first function declaration does result in a prototype
>being declared (internal to the compiler) and all future uses of
>auxiliary_func are checked against that prototype.
>
>In fact, the first use of a function, in the absence of a prototype,
>causes a prototype to be generated for that function based on the
>default argument promotion rules. This is not ANSI behavior, and can
>be disabled with the -P switch, but is very useful in checking for
>errors in old K&R code.
>
>The -r switch, strict prototyping, is also available, which enforces a
>rule that all uses of a function must have a prototype in scope for it.
>I use this switch for all my code, and recommend its use, as it results
>in the bugs being caught at the earliest possible time (when they are
>the cheapest to fix!).

Both C compilers I use (Turbo C on DOS and Microsoft C on OS/2) do the same 
thing. (At least from my perspective). Turbo C doesn't generate warnings or
anything at all, but takes a function definition as a prototype (it WILL warn
about mis-matched types in parameters in calls to functions with previous
definitions but no prototype.) Microsoft C generates a warning.

	foo.c(6) : warning C4103: 'main' : function definition used as prototype

The warning is generated, however, at the first call to the function versus 
the function definition. I guess the would be correct behaviour.

Just as a matter of course, however, I usually use prototypes on all functions,
since this helps with conflicts on the PC in regards to pointer sizes, etc
and it helps document the code, too.


Adding my $.02 (unless it has devaluated already)
Steve

-- 
----------------------------------------------------------------------------
steve.resnick at f105.n143.z1.FIDONET.ORG - or - apple!camphq!105!steve.resnick
Flames, grammar errors, spelling errrors >/dev/nul
The Asylum OS/2 BBS - (408)263-8017 IFNA 1:143/105.0