Xref: utzoo comp.std.c:4303 comp.sys.amiga.programmer:777
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!olivea!tymix!cirrusl!sunstorm!dhesi
From: dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi)
Newsgroups: comp.std.c,comp.sys.amiga.programmer
Subject: Re: ANSI prototypes, the right choice...
Message-ID: <2941@cirrusl.UUCP>
Date: 11 Feb 91 23:58:34 GMT
References: <7708@sugar.hackercorp.com> <15089@smoke.brl.mil> <1991Feb9.075215.26939@athena.mit.edu>
Sender: news@cirrusl.UUCP
Organization: Cirrus Logic Inc.
Lines: 29

My experience is that if you want to keep your code reasonably
portable to non-ANSI-C environments but also take advantage of
the additional compile-time checking provided by function
prototypes, then the best way to do this is mix the old and
new styles like this:

     int myfunc PARAMS((int i, char *p));
     ...

     int myfunc (i, p)
     int i;
     char *p;
     {...}

What's good about this style is:  (a) It is compatible with both ANSI
and non-ANSI C environments;  (b) In an ANSI C environment, most
reasonable compilers will give you all of the intra-file checking that
you get with new-style definitions; (c) In a UNIX environment lint is
still fully usable and will do cross-file checking (which ANSI C
compilers can't do).

The only disadvantage of the above strategy is that it does not take
advantage of the slight increase in efficiency that you get if you have
char or float parameters and they are declared in the new style so that
runtime widening is not needed.  I don't think this advantage is enough
to sacrifice portability by using new-style definitions.
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP:  oliveb!cirrusl!dhesi