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.