Path: utzoo!attcan!uunet!lll-winken!ames!ncar!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Yet another pcc botch
Message-ID: <15620@mimsy.UUCP>
Date: 25 Jan 89 07:44:08 GMT
References: <3310@cbnews.ATT.COM> <398@lakart.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 32

The program fragment:
	float g;
	unsigned short u, v;

	u = 250;
	v = 100;
	g = v - u;

>>... The correct value for g is -150.000000.

In article <398@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes:
>No. The correct value for g is 65386.0 [for 16 bit short].

Actually, the answer depends on two (or three) things:

If you implement classic C, the answer is some positive number.  The
type of (u_short-u_short) is the type of (expand(u_short)-expand(u_short))
which is (u_int-u_int) which is u_int.  65368 is a typical value.

If you implement pANS C, the answer depends on one thing:  The type of
(u_short-u_short) is either u_int or int.  If sizeof(int)>sizeof(short),
expand(u_short) is int, otherwise it is u_int.  I consider this `feature'
one of the major botches in the pANS (although something like it is
necessary to get unsigned chars to produce int values without casts).

Now, on a 3B, sizeof(int) > sizeof(short), so the answer depends
on whether your compiler implements classic C (65386.0) or pANS C
(-150.0).  But on a PDP-11, sizeof(int)==sizeof(short), so the
answer is 65368.0 in both classic C and pANS C.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris