Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: `char' parameters: a follow-up/summary
Keywords: parameter, K&R, ANSI C, narrowing, widening, promotion
Message-ID: <13460@mimsy.UUCP>
Date: 9 Sep 88 02:59:16 GMT
References: <1626@se-sd.sandiego.ncr.com>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 62

In article <1626@se-sd.sandiego.ncr.com> rns@se-sd.sandiego.ncr.com
(Rick Schubert) writes:
>What have I done wrong?  I posted an article asking a question and received
>an underwhelming response.  Didn't I insult the right people or stomp on
>anyone's dogma?

Apparently not.  Score par for USENET :-) .

>In <16432@apple.Apple.COM> bgibbons@Apple.COM (Bill Gibbons)
>quoted the Draft [section 3.7.1; just a little quoted.]

>He interprets this to mean that the `char' parameter MUST remain a `char',
>although the Whitesmiths' compiler does [not] do the adjustment.  One possible
>argument against this is that, if the compiler DOES do the adjustment to
>`int', then the "type of the corresponding parameter" is `int'.

[much more deleted]
>In conclusion, then, this is still an open issue in my mind.  I call on the
>wizards to speak up on this (not meant as a slight to anyone who has already
>spoken).  Karl Heuer?  Chris Torek?  Any others?  Help!

Oh dear, I seem to have been invoked :-) .

I make the same interpretation as Bill Gibbons.  Here is more of \S3.7.1
(`Semantics'):

    On entry to the function the value of each argument expression
    shall be converted to the type of its corresponding parameter, as
    if by assignment to the parameter.  Array expressions and function
    designators as arguments are converted to pointers before the
    call.  A declaration of a parameter as ``array of /type/'' shall be
    adjusted to ``pointer to /type/,'' and a declaration of a parameter
    as ``function returning /type/'' shall be adjusted to ``pointer to
    function returning /type/,'' as in \S3.2.2.1.  The resulting
    parameter type shall be an object type.

(/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.)

In the past, questions as to the C language definition have often been
resolved by asking what the C compilers did.  The Portable C Compiler
promotes `float's to `double's, but does no other promotion; on big-
endian machines such as the 680x0 and the Tahoe, it goes to the effort
required to convert `char' parameters (namely, adjust the stack offset).
Hence the 4.3BSD-tahoe Tahoe PCC will, for

	f(i, c) int i; char c; { g(i, c); }

generate the call

		pushb	11(fp)	# c
		pushl	4(fp)	# i
		callf	$12,_g	# g, 12/4 - 1 = 2 args

The consensus appears to be that `char' parameters must be narrowed
from `int's, and that a few compilers (the Whitesmith's named in the
parent article, e.g.) get it wrong.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris