Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: Significant deficiency in C
Message-ID: <7938@sun.uucp>
Date: Mon, 6-Oct-86 16:37:11 EDT
Article-I.D.: sun.7938
Posted: Mon Oct  6 16:37:11 1986
Date-Received: Tue, 7-Oct-86 23:39:36 EDT
References: <4200@brl-smoke.ARPA> <6129@alice.uUCp> <1372@jade.BERKELEY.EDU> <1229@bunker.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 26

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

The fact that the string "bug report" appeared there is irrelevant; it
connotes nothing.  This is not a problem with a particular C implementation.
The bug report merely indicates that the problem exists if a C
implementation doesn't follow the rules in question.  Presumably, they were
trying to be "clever" and evaluate the expression in question in 8-bit
arithmetic.

Unfortunately, this *is* one of the cases where you can't do it using 8-bit
arithmetic without changing the rules; in this case, 8-bit arithmetic is
inequivalent to 16-bit arithmetic, and if "int"s are 16 bits (as they
presumably are in this case), the C language requires that the results be
those produced by 16-bit arithmetic.

You can fix the bug by changing the code to use 16-bit arithmetic, in which
case you "get it right" in the sense of giving the right answer but not in
the sense of using 8-bit arithmetic.  You can also "fix" the bug by changing
the rules.  You can't get it right without changing the rules just fixing the
bug; the problem with the rules is not caused by the presence of a bug!
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)