ANSI/Non-ANSI Function Declaration Macros

[Peter Curran]

In article <22402 at princeton.Princeton.EDU> nfs at notecnirp.UUCP (Norbert Schlenker)
writes (in response to my suggesting for combining prototypes with the
obsolescent forms of functions, to port between ANSI and non-ANSI compilers):
|But there is a problem with this too!  With a K&R compiler, things work
|just fine using this scheme.  But with an ANSI compiler, any function
|taking a small argument (like char or short) will end up with a conflict
|between the prototype and the actual file header.  For example:
|
|extern void func(char c, short n);
|
|void func(c, n)
|char c;
|short n;
|{}
|
|won't be accepted.  The K&R definition is going to be treated as if
|it says:
|
|void func(c, n)
|int c;
|int n;
|{}
|
|since argument widening is automatic in K&R.  Then there is a terrible
|mismatch between the prototype and the definition, which every ANSI
|compiler that I have seen complains bitterly about.  So now you need to
|conditionally compile function headers, and that will always be less
|pleasant since it can't be done automagically by the preprocessor.

Not as far as I can see, unless I have badly mis-read the ANSI standard
(which is certainly possible :-))

First, I assume that, in ANSI, the following are exactly equivalent:

	void func (char c, short n)
	{...}
and
	void func (c, n)
	char c;
	short n;
	{...}

They are just different syntax for the same thing.  I would like to be
corrected if I have misunderstood this.

My prototype here would be

	void func P((char c, short n));


Assuming I am right, then the use of the obsolescent form of function
header is irrelevant (except that it allows the code to be compiled
with K&R compilers.)  ANSI compilers will see the prototype, and will
not widen the parameters; K&R compilers will not see the prototype
(which they can't handle), and will widen the parameters.  Assuming all
the code is compiled with the same compiler (i.e. both the function
and all calls to it), then widening will always be done, or it won't
be done.

I have ported a lot of code written this way, so I am pretty sure it
works.  I would love to abandon it, however... :-)