Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!nbires!vianet!devine
From: devine@vianet.UUCP (Bob Devine)
Newsgroups: comp.lang.c
Subject: Re: MSC C arithmetic
Message-ID: <218@vianet.UUCP>
Date: Fri, 14-Aug-87 21:44:18 EDT
Article-I.D.: vianet.218
Posted: Fri Aug 14 21:44:18 1987
Date-Received: Sun, 16-Aug-87 06:51:55 EDT
References: <8792@brl-adm.ARPA>
Organization: Western Digital, Boulder Tech Ctr
Lines: 25
Summary: behavior is correct

In article <8792@brl-adm.ARPA>, jdickson@zook.Jpl.Nasa.GOV (Jeff Dickson) writes:
> 	I recently wrote a program for the PC that performed some 
> arithmetic. I compiled the code using MSC 'C' 4.0 . The problem I
> had, was that simple integer and floating point arithmetic was not
> being carried out properly unless I explicitly cast the operands
> to the type of the result.

  But the operation was done properly; it was just unexpected to you.
According to the "usual arithmetic conversion rules" 2 ints will produce
an int.  If it so happens that overflow occurs because of the operation,
the resultant int value will simply not be the expected value.

  And as you discovered, according to the "usual arithmetic conversion
rules" where one operand is a long and the other an int, the operand
that is an int is converted to a long and the result is a long.  This
gave you what you wanted.

  Look up "arithmetic conversions" in K&R or "the usual binary conversions"
in Harbinson/Steele.  Sam Harbison posted a modified conversion list
to net.lang.c in '85.

  On PCs, an 'int' is 16 bits.  You have to use a long to hold the value
for the example code you posted.  Yeah, there are times I want a VAX too.

Bob Devine