Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: `char' parameters: a follow-up/summary
Keywords: parameter, K&R, ANSI C, narrowing, widening, promotion
Message-ID: <8471@smoke.ARPA>
Date: 9 Sep 88 07:25:44 GMT
References: <1626@se-sd.sandiego.ncr.com> <13460@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 24

In article <13460@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>(/Word/ denotes italics; \S is a section symbol.)  No mention is made
>of `promotion' of the types of arguments; indeed, this section appears
>to revoke the note in K&R 1st ed. that promotes float argument
>declarations to double.  (Personally, I think that this is a good
>thing.)

Remember, this discussion was specifically about behavior in the
absence of prototypes, i.e. "old style" functions.  Section 3.3.2.2
of the dpANS specifies that the "default argument promotions" (which
include integral promotions as well as float->double) are performed
on the arguments in a function call.  This much agrees with K&R I;
it is impossible to pass a char to an old-style function (it gets
widened to int before reaching the function).

What happens at the start of the function is different between many
existing implementations and dpANS C; the dpANS does not allow type
rewriting (where a parameter defined as "char" gets treated as though
it had been defined as "int").  This is noted as a "QUIET CHANGE" in
the Rationale document, which you should refer to for more details.

The only safe, portable way to have written such old-style functions
was to define the parameter as the widened type that was actually
passed, e.g. int instead of char.