Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!amdahl!apple!bgibbons
From: bgibbons@Apple.COM (Bill Gibbons)
Newsgroups: comp.lang.c
Subject: Re: `char' parameters
Keywords: parameter, K&R, ANSI C
Message-ID: <16432@apple.Apple.COM>
Date: 1 Sep 88 16:38:55 GMT
References: <1616@se-sd.sandiego.ncr.com>
Reply-To: bgibbons@apple.com.UUCP (Bill Gibbons)
Organization: Apple Computer Inc, Cupertino, CA
Lines: 37

In article <1616@se-sd.sandiego.ncr.com> rns@se-sd.sandiego.NCR.COM (Rick Schubert) writes:
>I believe I have found a bug in a C compiler I am using ...
>If I define a function `f' as follows:
>	f(c)
>	char	c;
>	{
>		...
>	}
>
>the compiler in question gives a warning that type type of `c' is
>being changed to `int'.
> ...

In section 3.7.1 of the draft standard, it says:
   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.

This is known as _narrowing_.  It is very important, for exactly the reason
you point out: if the parameter is not narrowed, and you take its address,
the pointer is to a different type than expected.

Narrowing is very easy for a compiler to do: for CHAR and SHORT, it just
adjusts the stack offset at which it thinks the value was passed, and changes
the type.  (On PDP11 etc, it doesnt even change the offset.)  Floating-point
is a little harder on most machines; it needs an explicit conversion.

This caused me a lot of effort last fall, when I was porting a UNIX application
to IDRIS running on an Atari box.  The Whitesmiths compiler did not do
narrowing, and I had to modify the code (with a tool) to add explicit
narrowing.  Without a tool to systematically change the code, it would have
been hopeless.  (After I got it working and it showed at Comdex, Atari
cancelled the product.  Fortunately, someone else was paying :-)

Bill Gibbons
(contractor)
bgibbons@apple.com