Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!yale!husc6!panda!genrad!decvax!ittatc!bunker!garys
From: garys@bunker.UUCP (Gary M. Samuelson)
Newsgroups: net.lang.c
Subject: Re: Significant deficiency in C
Message-ID: <1229@bunker.UUCP>
Date: Mon, 6-Oct-86 10:49:05 EDT
Article-I.D.: bunker.1229
Posted: Mon Oct  6 10:49:05 1986
Date-Received: Wed, 8-Oct-86 00:00:08 EDT
References: <4200@brl-smoke.ARPA> <6129@alice.uUCp> <1372@jade.BERKELEY.EDU>
Reply-To: garys@bunker.UUCP (Gary M. Samuelson)
Organization: Bunker Ramo, Trumbull Ct
Lines: 27

In article <1372@jade.BERKELEY.EDU> mwm@eris.UUCP (Mike Meyer) writes:
>In article <6129@alice.uUCp> ark@alice.UucP (Andrew Koenig) writes:
>>One would think that for many char operations it is possible for
>>the compiler to figure out that doing it in 8 bits and expanding to
>>16 at the end only if necessary will give the same result as expanding
>>to 16 bits immediately.
>>
>>Can you give us some examples of code that you think would be
>>impossible to get right without changing the rules?
>
>Yes. How about (from a bug report on Lattice C in net.micro.amiga):
>
>	char	x = 0XFF, y = 2, z ;
>
>	z = (x + y) / 2 ;
>
>If you do this in character arithmetic, you get 0 (1/2). If you do it
>as something longer, you get 128.

Unless, of course, char is considered signed, in which case the result
will still be 0.

(In any event, I am not sure that a 'bug report' is a valid source for
the kind of example Mr. Koenig is looking for.  Fix the bug, and then
it may be possible to get it right without changing the rules.)

Gary Samuelson