Path: utzoo!utgpu!watmath!att!dptg!rutgers!iuvax!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Re^2: Turbo C 2.0 vs MSC 5.1
Message-ID: <10689@smoke.BRL.MIL>
Date: 9 Aug 89 20:25:03 GMT
References: <644@octopus.UUCP> <3607@cps3xx.UUCP> <7368@cg-atla.UUCP> <527@tigger.planet.bt.co.uk>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 14

In article <527@tigger.planet.bt.co.uk> raph@tigger.planet.bt.co.uk (Raphael Mankin) writes:
>	int	i, j;
>	long	l;
>	l = i*j;
>MSC will compute i*j as 32 bits, discard the upper 16 bits and then sign
>extend the 16 bits back to 32 bits.

That's acceptable behavior.  If the operands were unsigned, discarding of
the high bits would even be required behavior.

Dealing with, or better yet avoiding, arithmetic overflow is tricky to do
right.  C explicitly does not constrain the implementation's behavior in
such a case, partly because any simple rule would not be universally
appropriate.