Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!ibmpa!ghoti!lmb
From: lmb@ghoti.uucp (Larry Breed)
Newsgroups: comp.lang.c
Subject: Re: ANSI/Non-ANSI Function Declaration Macros
Message-ID: <3344@ibmpa.UUCP>
Date: 18 Dec 89 22:03:10 GMT
References: <4603@itivax.iti.org> <244@isgtec.UUCP> <22402@princeton.Princeton.EDU> <248@isgtec.UUCP> <22472@princeton.Princeton.EDU>
Sender: news@ibmpa.UUCP
Reply-To: lmb@ibmsupt.UUCP (Larry Breed)
Organization: IBM AWD Palo Alto
Lines: 37

In article <248@isgtec.UUCP> peter@isgtec.UUCP (Peter Curran) writes:
>
>First, I assume that, in ANSI, the following are exactly equivalent:
>
[No. 1]
>	void func (char c, short n)
>	{...}
>and
[No. 2]
>	void func (c, n)
>	char c;
>	short n;
>	{...}

The answer is 'no', and it raises a point worth noting:  there is no Standard C
prototype declaration that portably matches the Classic C function in No. 2.

For the first definition, Standard C permits but does not require allocating only
a char-sized and a short-sized element in the argument list.  In fact many implementations
continue to widen such arguments and pass them in int-sized elements.

No. 2 is a Classic C function whose callers pass two int-sized arguments.  This *does not*
make it equivalent to 

[No. 3]
	void func (c, n)
	int c, n;
	{...}

In No. 2, c is truly a char.  Regardless of the width of the argument list
element, the value of c within the function definition must remain within the limits
for objects of char type.  Taking &c must produce a pointer to a char.  
It is true that callers would have to treat calls of nos. 2 and 3 identically,
in either a K&R or ANSI compiler environment.
Disclaimer: Don't blame my employer, blame:
Larry Breed			(415) 855-4460
uucp: uunet!ibmsupt!lmb		inet: ibmsupt!lmb@uunet.uu.net