Path: utzoo!attcan!uunet!sco!seanf
From: seanf@sco.COM (Sean Fagan)
Newsgroups: comp.lang.c
Subject: Re: function prototype problem
Message-ID: <1736@scolex>
Date: 17 Nov 88 05:59:22 GMT
References: <310@drd.UUCP> <1704@scolex> <8889@smoke.BRL.MIL>
Reply-To: seanf@sco.COM (Sean Fagan)
Distribution: na
Organization: The Santa Cruz Operation, Inc.
Lines: 42

In article <8889@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
}In article <1704@scolex> seanf@sco.COM (Sean Fagan) writes:
}-In article <310@drd.UUCP> mark@drd.UUCP () writes:
}->char *rpeet  ( short, char );
}->char *rpeet ( num, ch )
}->    short num;
}->    char ch;
}-I, however, maintain what what ANSI says is that, if you declare a function
}-using old-style declaration (as you did), then you do not expand the
}-arguments unless a prototype is given; but if you use newstyle declarations
}-(char *rpeet ( short num, char ch) {), everything is as if you had also
}-given a prototype.
}
}I don't have the draft Standard at hand right now, but I'm pretty sure
}Stallman is right to have gcc diagnose this.  Old-style function syntax
}requires widened arguments but the prototype indicates unwidened.  This
}is clearly a type clash.  It is possible that the draft Standard really
}says that a compiler has to straighten things out in cases like this
}example, but I would find it surprising (and dangerous).

Ooops.  Just got a nice new copy of the Draft, and you're right:  Section
3.5.4.3 (Funciton declarators (including prototypes)), page 66, lines 8-12:

	If one type has a parameter type list and the other type is
specified by a function definition that contains a (possibly empty)
identifier list, both shall agree in the number of parameters, and the type
of each prototype parameter shall be compatable with the type that results
from the application of the default argument promotions to the type of the
corresponding identifier.

Ok.  Something I may have to look in for MSC.  I still think that somebody
should fix it so that GCC will accept the mixture, unless -ansi, or
-pendantic, is specified, but that's just me (or appears to be 8-)).

So, the moral of the story:  Don't pass in char's, short's, or float's to
your subroutines unless you want a Real(tm) ANSI C compiler to choke on it
8-).

-- 
Sean Eric Fagan  | "Engineering without management is *ART*"
seanf@sco.UUCP   |     Jeff Johnson (jeffj@sco)
(408) 458-1422   | Any opinions expressed are my own, not my employers'.