Any GOOD reason for C's behaviour in this example?

Daniel R. Levy levy at ttrdc.UUCP
Tue Jul 22 15:37:32 AEST 1986


I recently came across a situation in C which caused me to do a double
take, at least until I dug out my trusty, dogeared K&R:

main()
{
	unsigned short a, b;
	int i;
	a=4;
	b=5;
	i = ( (int) a) - ( (int) b);
	(void) printf("%d\n",i);
	return 0;
}

Now, silly me, I was half expecting that casting the unsigned short values
to ints would make them be treated as ints in an expression which takes a
difference between two of them.  (The machine being used was a 3B2, which
has two-byte unsigned shorts and four-byte ints.)

However, I initially did a double take when I found that code such as
exemplified in this little program produces a result exemplified by:

65535

Now deep in the bowels of K&R there is a paragraph explaining that
indeed this is what is supposed to happen and so I am not going to
holler about "oh, I have a broken C compiler" or any such nonsense.
(My own company, AT&T, produces the compiler I am working with; ergo it
CAN'T be broken and if you say it is I'll flame-fight you to the death :-).)

But what I'd like to ask is, philosophically, WHY does C expression evaluation
behave in this way?  Is there really a good reason of language design or usage
(other than, obviously, being consistent with existing convention) that you
would NOT want casts within a C expression to act as if they converted the
individual variables or expressions to which they referred into the type of
the cast, regardless of whatever else goes on, before including them in the
evaluation of the entire expression?  I mean, I feel it is rather silly to
have to sidestep what, to me, seemed to be a clear intent with something
like this:

main()
{
	unsigned short a, b;
	int i, j;
	a=4;
	b=5;
	i = a;
	j = b;
	i -= j;
	(void) printf("%d\n",i);
	return 0;
}

Comments, suggestions, even flames (mild ones; my asbestos is still glowing
from my last round :-) ) are welcome.  Post or mail, and thanks in advance.
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
	   go for it!  			allegra,ulysses,vax135}!ttrdc!levy



More information about the Comp.lang.c mailing list